« first day (3905 days earlier)      last day (40 days later) » 

3:42 AM
systemctl restart wpa_supplicant.service
what is it about wpa_supplicant that makes it die after about a month of use?
 
 
9 hours later…
12:35 PM
@terdon The unquoted < is a redirection (in [ ... ], not in [[ ... ]]). Quoting it makes it compare sort order. — Kusalananda ♦ 36 secs ago
@Kusalananda ?
 
Yep.
 
How would you quote the < ?
 
'<'
Remember, [ is just a utility. < is a redirection into it.
 
Will you please stop blowing my mind today? This is the third time you've pointed out something incredibly basic that I didn't know! :P
 
[[ is a keyword though, so < is just a token, part of the syntax related to the [[.
;-)
 
12:38 PM
Damn.
 
 
1 hour later…
1:51 PM
Also, < in [ .. ] is nonstandard, but in the funny way that Ksh and Zsh don't seem to support it, while Dash, Yash and Busybox seem to do(?) And while Bash has it, test from GNU coreutils doesn't.
 
2:11 PM
@ilkkachu Possibly even more funny:
$ ksh -c 'test a \> b; echo $?'
1
$ ksh -c 'test b \> a; echo $?'
0
$ ksh -c 'test a \< b; echo $?'
ksh: test: <: unknown operator
2
(ksh from kornshell.org)
 
@fra-san is test a builtin in ksh? My man ksh says it isn’t...
but my ksh doesn’t complain about test a \> b while /usr/bin/test does
 
@StephenKitt [ and test are builtins in my ksh.
 
@fra-san yes, same here, in spite of the manual
 
2:30 PM
@fra-san right, I tested with < only :D
 
3:11 PM
@JeffSchaller @Kusalananda: I heard you like emojis: github.com/StarPlayrX/bigmac
 
 
3 hours later…
6:04 PM
macos's "security" protections are starting to (have always been) get out of hand
not allowed to edit /etc/sudoers
 
Not even with visudo?
 
6:21 PM
@terdon Nope, I was able to sudo sed -i.bak but for some reason nothing else worked, even running vscode with sudo would fail to save the file
visudo: /etc/sudoers: Operation not permitted
Every time I change the permissions of /usr/local/bin they get reverted back too
 
@jesse_b that seems really weird. Are they providing some sort of GUI replacement or something?
 
I think they just don't want you modifying anything
I don't need my operating system to protect me
well sometimes I do but I never want it :p
 
@jesse_b What macOS verison are you on? On "big sur" I can definitely edit the sudoers file with sudo visudo.
 
@Kusalananda big sur yes
sudo visudo gives the same error as above
 
@jesse_b And on Catalina.
@jesse_b Makes me think you've messed something up.
Have you played around with disabling SIP?
 
6:27 PM
11
A: `sudoers` file resets with every macOS update

Tony WilliamsModifying most of the files in /etc leaves you open to them being replaced during OS updates. That's why most of the ones you usually need to change have the facility to add files to a directory instead. If you look in /etc you will see a directory called sudoers.d and the last line of the sudoer...

I just don't like the things macos does to mess with standard unix-y things. RABBLE RABBLE RABBLE
I don't want to have to disable sip to perform a basic function of unix
 
@jesse_b macOS being a standard Unix doesn't matter?
@jesse_b Well, you have the solution in that post. Create a file in the sudoers.d subdirectory.
 
IMO macos is just a gui running on top of BSD
 
@jesse_b That's the Finder you're talking about. Yes, it's a GUI on top of a BSD system.
That BSD system inherits a lot from FreeBSD, but it does enough of things differently to be called its own OS.
 
The reason people prefer mac is because it's a well (debatable) developed desktop operating system with unix under the hood, but the more of that unix they take away the less incentive to use it
 
I don't see what they have taken away though.
In the particular case we're talking about now, there is an easy solution, which IMHO is good and the way to do it even on a Linux system.
 
6:40 PM
rabble rabble rabble
 
:-)
I'm off for another walk.
 
why do they keep changing the permissions of my /usr/local/bin directory?
3
Q: How to add new dictionaries to /usr/share/dict/

jesse_bI'm trying to add a new word file to /usr/share/dict/ on macOS Catalina v 10.15.1 and I'm getting: $ sudo touch /usr/share/dict/mywords touch: /usr/share/dict/mywords: Operation not permitted # touch /usr/share/dict/mywords touch: /usr/share/dict/mywords: Operation not permitted I've read some...

Operation not permitted is too common a theme on macos
 
6:52 PM
@jesse_b It seems locally install dictionaries fit best in /usr/local/share/dict, don't you think?
Just like on other BSD systems, the base system on macOS shouldn't be modified willy nilly.
 
I do things willy nilly
 
Other BSDs, like OpenBSD, have elaborate merging tools to handle locally modified files when the system is updated. Sometimes, updates conflict with local changes, and a manual fix has to be made.
 
Also see my complaints about /usr/local
 
macOS, being aimed at slightly less nerdy people, obviously can't have the user handle conflicts in system configs.
 
evidently macos feels I shouldn't be modifying anything in /usr/local either
 
6:55 PM
Sorry, what was that about /usr/local? Permissions? What permissions do you want and what do you get and when?
 
I want to be the owner of /usr/local or at least have write permissions to it. I can make those changes but they are automatically reverted every time I reboot
 
Aro you talking about /usr/local itself or about some subdirectory? The local directory lives in /usr, which, again, is base system.
 
either
Changes to /usr/local revert, changes to /usr/local/bin revert
 
I own all my sudirectories under /usr/local, and can write to them. This is on both Catalina and Big Sur. I don't see the ownership or permissions change on reboots or updates.
drwxr-xr-x and drwxrwxr-x permissions.
 
I actually do own most of the directories under /usr/local though now that I'm looking at it, it's just /usr/local/bin that keeps reverting for some reason
I'm definitely not the only person with that problem though because when you google it you find a lot of people complaining about it because it breaks homebrew
and people recommend changing the directory where homebrew installs to ~/usr/local/bin but just thinking about having a ~/usr/local/bin makes me throw up in my mouth a bit
and again I don't want my operating system to "protect" me. I want to do dangerous stuff
 
 
1 hour later…
8:31 PM
@jesse_b it's not about protection. It's about asserting dominance.
2
 
@AndrasDeak :(
 
 
1 hour later…
9:45 PM
I hmmm i now dont know what to do after the threat of ban if i post more questions. do all the stack exchange communities socially interact? i feel like if its based on what people have said i said in other communities that i specifically joined to make fun of when im drunk shouldnt affect my access here
i just wanna know how you can retrive information about the nature of how ports are filtered and for which services they are used if it is possible with nmap
 
10:06 PM
@jesse_b A good system will be designed to allow you to do what you want, while still providing protection (e.g. mandatory access controls). But an unprotected system is bad.
 
@AdamL A service can listen to any port. There are a number of port numbers that are associated with particular services though, like SSH on port 22 and DNS on port 53. Have a look at your /etc/services file for a fuller list.
 
Any port if it has sufficient privileges.
 
@forest And if it's not otherwise used.
 
Also, although in theory you could use port 0, in practice that's used to mean "any port" by OS' network API, so no one actually listens on port 0. But it may be useful for covert comms. :P
@AdamL You can find out which ports are open generally, but you can't always find out what service is running unless you can talk to it (although you can guess what's running behind it if it's a common port). But port 1234 with an HTTP server that only allows certain IPs to connect won't be shown to you as HTTP by nmap.
@AdamL Not all SE communities interact with each other, at least not often.
Oh, MacOS... Yeah, that's not well protected. :P
@Kusalananda OpenBSD is great at that! Gentoo also handles merging configs well.
 

« first day (3905 days earlier)      last day (40 days later) »