4 ms·

This is a valuable effort for portability. I had no idea `source` was not POSIX compliant but `.` was, or what flags `grep` doesn’t support on macOS. But it is

by nequo 4y ago

This is a valuable effort for portability. I had no idea `source` was not POSIX compliant but `.` was, or what flags `grep` doesn’t support on macOS. But it is ironic that the script uses `echo` to show a message that `printf` is preferred to `echo`. I guess what is meant is that `printf` is preferred to `echo -[en]`.

remram 4y ago
echo is fine when its argument is not a variable.
- hvdijk 4y ago
  The script does echo variables: echo "banned command $cmd: $output" This is non-portable if there is any possibility that these variables contain backslashes.
  - nequo 4y ago
    TIL: dash$ x="foo\nasd" dash$ echo "$x" foo asd dash$ printf "%s\n" "$x" foo\nasd dash$ zsh% x="foo\nasd" zsh% echo "$x" foo asd zsh% printf "%s\n" "$x" foo\nasd zsh% bash$ x="foo\nasd" bash$ echo "$x" foo\nasd bash$ printf "%s\n" "$x" foo\nasd bash$
    - fragmede 4y ago
      bash$ echo -e $x foo asd bash$
    - norvvryo 4y ago
      Enlightening From POSIX: >echo - write arguments to standard output >If the first operand is -n, or if any of the operands contain a <backslash> character, the results are implementation-defined.
      - deleted 4y ago
        [deleted]
    - remram 4y ago
      Wow, TIL indeed. That's conformant to the Single UNIX Specification as well: https://pubs.opengroup.org/onlinepubs/007908799/xcu/echo.html https://pubs.opengroup.org/onlinepubs/007908799/xcu/echo.htm...
  - TechBro8615 4y ago
    The script is for static analysis, so it only needs to run once against each code change, and in theory it shouldn't need to be portable code, unless the code under test is the static analysis code itself. In other words, they control where this script runs and there is no need to run it on more than one platform, so it's okay for it to be non-portable.
    - hvdijk 4y ago
      That's fine if the script only runs on shells that behave the same way, but the script runs under bats, which runs on bash and appears to not change its xpg_echo shell option. This shell option controls echo's behaviour on bash and has a compile-time-configurable default; even scripts that are only meant to run on bash cannot assume either behaviour for echo, as different vendors use different defaults for the option.
heynowheynow 4y ago
sed, grep, and find are radically different on macOS (4.4BSD + early FreeBSD + many hacks since).
- reisse 4y ago
  Once upon a time I was writing a few portable shell scripts for Solaris and Linux distros. Limiting the scripts to a common subset of commands was fighting windmills - so often you stuck with something easily solved by one GNU option, but requiring 10+ lines of shell script with UNIXy commands on Solaris. In the end, it was much easier to just proclaim GNU coreutils as a dependency everywhere, and use g-prefixed versions of commands (gfind, ggrep, and so on).
  - salmo 4y ago
    Even the GNU commands on Solaris were so old, and from a time where so many were changing and flakey. I could reliably make the Solaris and early Linux bash and gsed segfault. Options weren’t consistent with Linux distros or coreutils from eg ports on FreeBSD. I still have a bias against GNU from those battle scars. I had to stick to (most of) POSIX across Unixes with ksh88/mksh/pdksh back in the day when my work had to be portable across Linux, BSD, Solaris, HP-UX, and AIX. I could rely on process substitution, etc. but stay vanilla outside the shell itself. Honestly the only really annoying thing to me was that sed -i didn’t mean in place, but even then it wasn’t reliably atomic IIRC. Handling the actual OS commands was much harder. Separate commands instead of getent (maybe getpw was one?) on HP-UX pops into my head.
aasasd 4y ago
I vaguely remember that `source` appeared in Bash at some version—presumably because it's clearer than the rather random `.`, and doesn't stand out among other built-ins for no good reason.

by nequo 4y ago

remram 4y ago

echo is fine when its argument is not a variable.

hvdijk 4y ago
The script does echo variables: echo "banned command $cmd: $output" This is non-portable if there is any possibility that these variables contain backslashes.
- nequo 4y ago
  TIL: dash$ x="foo\nasd" dash$ echo "$x" foo asd dash$ printf "%s\n" "$x" foo\nasd dash$ zsh% x="foo\nasd" zsh% echo "$x" foo asd zsh% printf "%s\n" "$x" foo\nasd zsh% bash$ x="foo\nasd" bash$ echo "$x" foo\nasd bash$ printf "%s\n" "$x" foo\nasd bash$
  - fragmede 4y ago
    bash$ echo -e $x foo asd bash$
  - norvvryo 4y ago
    Enlightening From POSIX: >echo - write arguments to standard output >If the first operand is -n, or if any of the operands contain a <backslash> character, the results are implementation-defined.
    - deleted 4y ago
      [deleted]
  - remram 4y ago
    Wow, TIL indeed. That's conformant to the Single UNIX Specification as well: https://pubs.opengroup.org/onlinepubs/007908799/xcu/echo.html https://pubs.opengroup.org/onlinepubs/007908799/xcu/echo.htm...
- TechBro8615 4y ago
  The script is for static analysis, so it only needs to run once against each code change, and in theory it shouldn't need to be portable code, unless the code under test is the static analysis code itself. In other words, they control where this script runs and there is no need to run it on more than one platform, so it's okay for it to be non-portable.
  - hvdijk 4y ago
    That's fine if the script only runs on shells that behave the same way, but the script runs under bats, which runs on bash and appears to not change its xpg_echo shell option. This shell option controls echo's behaviour on bash and has a compile-time-configurable default; even scripts that are only meant to run on bash cannot assume either behaviour for echo, as different vendors use different defaults for the option.

heynowheynow 4y ago

sed, grep, and find are radically different on macOS (4.4BSD + early FreeBSD + many hacks since).

reisse 4y ago
Once upon a time I was writing a few portable shell scripts for Solaris and Linux distros. Limiting the scripts to a common subset of commands was fighting windmills - so often you stuck with something easily solved by one GNU option, but requiring 10+ lines of shell script with UNIXy commands on Solaris. In the end, it was much easier to just proclaim GNU coreutils as a dependency everywhere, and use g-prefixed versions of commands (gfind, ggrep, and so on).
- salmo 4y ago
  Even the GNU commands on Solaris were so old, and from a time where so many were changing and flakey. I could reliably make the Solaris and early Linux bash and gsed segfault. Options weren’t consistent with Linux distros or coreutils from eg ports on FreeBSD. I still have a bias against GNU from those battle scars. I had to stick to (most of) POSIX across Unixes with ksh88/mksh/pdksh back in the day when my work had to be portable across Linux, BSD, Solaris, HP-UX, and AIX. I could rely on process substitution, etc. but stay vanilla outside the shell itself. Honestly the only really annoying thing to me was that sed -i didn’t mean in place, but even then it wasn’t reliably atomic IIRC. Handling the actual OS commands was much harder. Separate commands instead of getent (maybe getpw was one?) on HP-UX pops into my head.

aasasd 4y ago

I vaguely remember that `source` appeared in Bash at some version—presumably because it's clearer than the rather random `.`, and doesn't stand out among other built-ins for no good reason.