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.
Isn't that name editable on your Apple ID page? That name is also not part of your financial data on the iPhone (which usually involves your real name).
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...?
I do not know details here. But there is, in fact, a separate “proprietary” API for interacting with files on macOS, provided for backwards compatibility. This API exists because the POSIX file functions do not provide similar enough functionality to the earlier API. This API is called the File Manager. Documentation is hard to find on the Apple website, but you can find some fairly extensive documentation for it in the old Inside Macintosh series (and sometimes you can dig HTML or PDF versions of this on the Apple website, but whether this is possible, and the exact location, seems to change every couple years).
The way you would specify a file on old versions of macOS used a length-delimited string for the filename, and referred to directories by 32-bit IDs. This was packed into an FSSpec structure which was passed to most functions which operated on files. Being length-delimited, it is possible to pass a NUL byte.
From what I understand, the macOS kernel exposed some additional entry points for these functions to operate correctly.
Pre-posix macOS (previously known as ‘system N’ where N was the version number) did indeed use pascal calling conventions, so the posters assertions aren’t unreasonable.
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)
The minor modification would be from `$opts` to `$=opts`.
I'd been using ZSH for a year as if it was Bash with better history and much better completions. The difference mentioned above was the only one I knew about. I kept writing my scripts in Bash and was quite happy with the UX.
>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.
Cool! I do use shebangs, but my concern is that moving forward bash may not be ported to macOS. (Or will I probably be able to, worst case, compile it myself?)
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)
Yeah, I went that route before settling into Oh-My-Zsh. The thing is, those single lines add up quick leading to increased mental overhead and time investment.
It's never been about 'understanding' zsh or not, it's always been about making it comfortable to use, quickly, on any given system I might use.
Sometimes a nice set of defaults is more productive than a custom solution.
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 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.
fish doesn't try to support all of the weird historical quirks of Bourne-style shells, so its grammar and built-in 'API' are far simpler and clearer. Its out-of-the-box configuration is much much nicer for most people than zsh's. Completion definitions are easier to read/write. Its source code seems less byzantine. And its GitHub-based development model is more accessible.
The down side is that it's functionally very limited compared to zsh. fish's completion functions are easy to maintain, but the trade-off is that they don't offer the fine-grained contextual control over behaviour that zsh's do. Features like globbing, sub-shells, job control, co-processes, modules, &c., are absent or extremely limited. There are fewer knobs and switches, though as mentioned it tries to do the right thing for most people by default. And a consequence of the syntax being clearer is that it's also much more verbose, which i guess you may or may not appreciate.
Over-all i think fish is a good shell for the (very common) type of person who doesn't really care about shells but was drawn to zsh just because it has nicer completion than bash and lets you write fancy prompts. I don't think it's a good fit, yet, for people who write complex scripts or regularly make use of stuff like extended globs, background jobs, and fancy parameter expansions.
Job control should be fully featured - backgrounding, stopping/continuing, and disowning are all implemented. If there's something missing we'd definitely look at adding it.
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.