Testing and Benchmarking of AI Compilers
broune.com1 pointsby chubot0 comments
$ dash -c 'echo "c:\\new"'
c:
ew
$ busybox ash -c 'echo "c:\\new"'
c:\new
It requires 4 backslashes: $ dash -c 'echo "c:\\\\new"'
c:\new
$ busybox ash -c 'echo "c:\\\\new"'
c:\\new
I am not sure this is a matter of "undefined behavior in POSIX" -- I think it might just be dash being wildly unconformant, which I have seen in other cases. osh-0.37$ echo "c:\new"
c:\new
osh-0.37$ shopt --set no_parse_backslash
osh-0.37$ echo "c:\new"
echo "c:\new"
^
[ interactive ]:6: Invalid char escape in double quoted string (OILS-ERR-12)
It really should be echo "c:\\new" # with two backslashes
That is an unambiguous program that works in every shell. In a well-written shell program, the only things that should follow a single backslash in a double quoted string are \ " ` $
(Although I found that this option is only on in ysh, not in shopt --set strict:all ... arguably that should be changed) $ bash -c 'echo hi | read x; echo $x' # no output
$ zsh -c 'echo hi | read x; echo $x'
hi
And then that affects this case: bash$ sleep 5 | read
^Z
[1]+ Stopped sleep 5 | read
zsh$ sleep 5 | read # job control doesn't apply to this case in zsh
^Zzsh: job can't be suspended
So yeah the semantics of shell are not very well specified (which is one reason for OSH and YSH). I recall a bug running an Alpine Linux shell script where this difference matters -- if the last part is NOT forked, then the script doesn't run - testing
- reviewing, and reading/understanding/explaining
- operations / SRE
[email protected]