3 ms·
Bash actually has a POSIX compatibility mode. There is a great deal in POSIX that was not in Bourne, native arithmetic expressions being the first to come to m
by chasil 4y ago
Bash actually has a POSIX compatibility mode.
There is a great deal in POSIX that was not in Bourne, native arithmetic expressions being the first to come to mind, then new-style command substitution.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
All of the POSIX utility standards, including the grep variants, can be found in the URL's parent directory:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ https://pubs.opengroup.org/onlinepubs/9699919799/utilities/
If this new GNU grep functionality becomes widely distasteful, I think that OpenBSD's grep tries to emulate GNU in a few ways, and could supplant it, becoming the system grep while "gnugrep" is relegated to the shadows.
It is also extremely expensive on Windows for a version of grep to be implemented as a shell script. Launched by xargs, the penalty will be severe.
The commercial platforms based upon GNU are in a marriage of convenience, and can easily pick and choose.
- kps 4y ago> Bash actually has a POSIX compatibility mode. It's partial. A short example is `date&>FILE`. [edited typo] On a POSIX shell, `date` will run in the background and the date will be written to stdout (`date&`) and `FILE` will be created or truncated (`>FILE`). Using `bash --posix`, the date will be written to `FILE`, since the incompatible bashism `&>` still takes priority.
- chasil 4y agoI agree that is ambiguous. If I were writing such a script where I wanted to launch a background process, and then create/truncate a file, I myself would separate them: date & >FILE Bash wouldn't mistake that, but a lot of shell scripts look like line noise and there are situations where bad form is required (quoted in an ssh, for example). Obviously, people wanting the bash functionality in POSIX would: date > file 2>&1 Bash discourages the latter form in my man page, but anyone interested in portability knows how profoundly bad that advice is.
- 1vuio0pswjnm7 4y agoYikes. This is why I do not use bash. Too complicated. For Linux, I added tab autocomplete to dash and use that for both interactive and non-interactive shell instead of bash. Saves keystrokes and bytes. No need to keep typing "#!/bin/sh" into every script.
- chasil 4y agoYou can compile dash with a line editing library, but it does not come in most packages.
- 1vuio0pswjnm7 4y agoI use libedit. I am used to NetBSD sh; dash is similar, derived from the same source. I wanted dash to behave more like NetBSD sh, so I changed it. Anyway, I am not a huge fan of "packages". (The problems described in this thread are one reason why.) Of course I use packaged binaries in some instances, but normally I only install them when needed, use them and then uninstall them when I am done. I prefer to compile the kernel and userland myself. That includes the shell. Simply compiling dash with libedit does not provide tabcompletion. Need to make some small changes.
- chasil 4y agoI just checked OpenBSD, and I find that there are 6 total links in /usr/bin: egrep, fgrep, grep, zegrep, zfgrep, and zgrep. The OpenBSD package is superior. The GNU gzip package includes a zgrep shell script that is adapted from work by "Charles Levert <charles@comm.polymtl.ca>" - this is similarly adapted for bzgrep and xzgrep. The OpenBSD implementation will have superior performance for zgrep, because it is native C. rebel$ ls -li /usr/bin/*grep 466612 -r-xr-xr-x 6 root bin 31520 Apr 11 2022 /usr/bin/egrep 466612 -r-xr-xr-x 6 root bin 31520 Apr 11 2022 /usr/bin/fgrep 466612 -r-xr-xr-x 6 root bin 31520 Apr 11 2022 /usr/bin/grep 466711 -r-xr-xr-x 2 root bin 15288 Apr 11 2022 /usr/bin/pgrep 466612 -r-xr-xr-x 6 root bin 31520 Apr 11 2022 /usr/bin/zegrep 466612 -r-xr-xr-x 6 root bin 31520 Apr 11 2022 /usr/bin/zfgrep 466612 -r-xr-xr-x 6 root bin 31520 Apr 11 2022 /usr/bin/zgrep