movablesed

AirDrop also shares your full name (seemingly the one associated with your Apple ID, not what you have set for yourself in your contacts), both by displaying it in the sharing interface on the involved devices and by attaching it as an extended attribute to uploaded files.

The latter is more serious imo, because those attributes live on your file system basically for ever, and they're preserved when transferring to another compatible file system or even when archived in a zip file. The meta-data can ride along with the files to completely unrelated systems even years after the fact. So if you AirDrop some files to your computer and then zip them up, anyone you send that zip to (a journalist, a public file-hosting site, w/e) will have your full legal name to go with them.

Even sharing your name through the interface seems questionable -- the fact that you and another person have each other's phone numbers is not necessarily an indication that you want to share your real names with each other. (Though i guess someone could usually find it out anyway if they already had your phone number.)

I reported this to Apple, but i don't think they care. Seems like it's by design.

If by '99% coverage' you mean it can complete the command's options, and know which of them take arguments, and maybe even know about sub-commands, yes. zsh's _arguments, and its _gnu_generic wrapper, can do that — just compdef whatever command to _gnu_generic and it'll pull the options and descriptions out of the --help output for you. fish does something similar, and maybe bash-completion has it too, idk.

But, even with relatively simple commands, that type of completion is very limited compared to the contextual functionality that proper zsh completion functions provide. These functions know...

* Which arguments are meaningful to complete more than once — there's no reason to complete `-a` again after you've already entered `ls -a`, but an option like `-v` might be cumulative

* Which arguments are meaningful to complete in the presence of other arguments — there's no reason to complete `-A` if you've already entered `ls -a`, since those two options are exclusive

* Whether the command supports permutation — GNU tools usually do (`ls mydir/ -al`), BSD ones usually don't (`ls -al mydir/`)

* Whether options can be stacked — some commands require `-a -b -c` instead of `-abc`

* How options can be joined to their optargs — GNU supports both `--foo bar` and `--foo=bar`, curl supports only `--foo bar`, grep supports both `-m 3` and `-m3`, tree supports only `-L 3`

* How the current argument might be affected by a previous one — if you've entered `make -C mydir` it's useful to complete targets from mydir/Makefile

* How to complete multi-part arguments — if you press tab after `ssh foo@` you probably want to complete a host name or IP

* The descriptions of arguments — zsh can explain what the difference between `always` and `auto` is, and even when an argument is arbitrary, it can explain what format it takes, what the default is, what the min/max are, &c.

* Probably most importantly, the values of optargs and operands — just blindly offering file names or presenting a metavar parsed from --help (like WHEN or TYPE) is not very nice; a useful completion function will offer package names, man-page names, compression levels, PIDs, NIC addresses, or whatever else is appropriate

I know it's technically possible to do some of this with bash completion functions, but most don't, probably because the infrastructure isn't there. fish is nicer, but even it doesn't (can't?) usually go that far with it.

This level of richness (along with related UI stuff like menu selection) is why a lot of people switch to zsh even if they don't really care about its scripting features and modules and stuff. It's probably why i started using it originally.

A way to specify completion behaviour declaratively would be really cool, but if it's just going to be dumbed down to bash-like functionality, i'm not sure it's going to gain much more traction with zsh users than _gnu_generic and bashcompinit (zsh's bash-completion compatibility shim) have.

What do you mean 'rewrite unlink'? As far as i know, none of the standard POSIX/C file-manipulation functions, including unlink(2), have ever supported NUL bytes embedded in file names. Path arguments to those functions are all NUL-terminated strings, as are exec*() process arguments, so it would be impossible to manipulate or reference those files using any of the standard APIs or command-line tools.

I can't think of how macOS could have previously supported NUL bytes in file names without those files existing in a separate universe that can only be interacted with by software that uses some proprietary Apple API. And if that's really how it worked, i feel like that was the real mistake all along...?

As the other person said, if your scripts are executables with an sh or bash 'shebang' at the top, they will continue to use the same shell they always did.

But if you did want to run them with zsh, most simple scripts that just set environment variables, string together commands, or redirect to files should work without any changes. The most obvious difference for basic scripts like that is that zsh doesn't split parameter-expansions on white space by default (so if you did something like `opts='-a -b -c'; mycmd $opts` it wouldn't work without additional, minor, modifications)

I agree that zsh's default configuration sucks (and the new-user wizard is overwhelming). I would like the project to provide a more opinionated set of defaults to OS vendors; i think we are probably just nervous about breaking 30 years' worth of expectations, and so far nobody has really pushed for it.

But i do think the misunderstanding i mentioned is very common, as illustrated by the fact that the GP seems to think that OMZ itself provides zsh's completion functionality. It's also a frequent point of confusion with people seeking assistance on zsh's IRC channel.

zsh doesn't require any 'plugins' for its tab-completion, everything you need is distributed with the shell. A lot of people who use zsh just don't understand how it works and think that OMZ/Prezto/whatever are doing something special for them that they couldn't achieve themselves with one line in their .zshrc (or that may even be enabled by default in their OS's global zshrc, as is the case on Ubuntu for example)

Is that what they've done? The linked article doesn't say that.

zsh isn't a perfect super-set of bash (there are some differences in syntax, provided built-ins, &c.), but it does have equivalents for most of bash's functionality. Off the top of my head i can't think of anything useful that it's missing. People may have subjective preferences for e.g. readarray over parameter expansion, but the functionality is all there. I suppose it doesn't (and probably never will) fully conform to POSIX, if that's important to you

You probably don't need to update /etc/shells unless you really want to. chsh just won't let you switch to a shell that's not listed there without using sudo, which isn't a problem for most (generally single-user) Mac systems. You can also change your shell from the Users & Groups system preferences (in the advanced settings).

bash's EPOCHREALTIME was inspired by mksh, which was in turn inspired by zsh. And in zsh, EPOCHREALTIME was named after the system real-time clock (specifically the CLOCK_REALTIME clock ID passed to clock_gettime()). And i imagine that was named by analogy with hardware real-time clocks, since they both track human ('real') time. But i don't know much about electronics or the history of POSIX clock sources.