‘command … &’ creates subshell
Dear maintainer, I believe, that the current behaviour of GNU Bash: $ command cat & [1] 3831 $ ps --pid $! --ppid $! PID TTY TIME CMD 3831 pts/300:00:00 bash 3832 pts/300:00:00 cat is problematic. Namely it is: 1) unexpected, as (a) it does not seem to be documented, (b) itʼs counter-intuitive and (c) other bourne-like shells (busybox ash, dash, ksh93, mksh, zsh) does not do that; 2) inconvenient, as in some cases PID of the parent shell is not an appropriate substitute for the PID of the real process. signature.asc Description: PGP signature
Re: ‘command … &’ creates subshell
Chet Ramey wrote: > On 6/29/20 4:33 PM, Dmitry Alexandrov wrote: >> 1) unexpected, as (a) it does not seem to be documented, (b) itʼs >> counter-intuitive and (c) other bourne-like shells (busybox ash, dash, >> ksh93, mksh, zsh) does not do that; > > It's an opportunity for optimization, not a bug I am not saying that this is a bug, only that it is inconsistent with almost any other bourne-like shell. >> 2) inconvenient, as in some cases PID of the parent shell is not an >> appropriate substitute for the PID of the real process. > since the results are correct. The results are _different_ across shell and, unfortunately, results provided by Bash are the least useful. Consider: $ command … & [1] 30737 $ strace -p $! strace: Process 30737 attached wait4(-1, :-/ signature.asc Description: PGP signature
Re: ‘command … &’ creates subshell
Eli Schwartz wrote: > Useful replacements: Thank you. Yes, I have to pick up habit to post known user-level workarounds along with bugreports. > If you need to ensure a disk executable is used, Of course. Why ‘command’ otherwise? > $ "$(type -P cat)" & > [1] 2092352 > $ ps --pid $! --ppid $! > PID TTY TIME CMD > 2092352 pts/42 00:00:00 cat Also: $ (exec cat) & [1] 31427 $ ps --pid $! --ppid $! PID TTY TIME CMD 31427 pts/300:00:00 cat Which, IIUC, is somewhat closer to what other shells do, though I cannot come up with any idea what practical difference it might make. signature.asc Description: PGP signature
Re: ‘command … &’ creates subshell
Robert Elz wrote: > | > If you need to ensure a disk executable is used, > | Of course. Why "command" otherwise? > > That doesn't actually work, "command" can run built-ins Ah, yes, thanks for correction. > there is actually no method ‹…› which guarantees execution of an executable > from an external file, other than by using the complete path name Well, I am not sure whether itʼs guaranteed, but the ‘exec’ as above does execute an external command in GNU Bash. signature.asc Description: PGP signature
Re: ‘command … &’ creates subshell
Robert Elz wrote: > The whole point of trying to find a technique like was hoped for using > command, and others have used env for, and still others, (exec command) (none > of which are guaranteed to work) is so that the script will work with > different shells and in different environments. One could argue, that an ability to ignore builtin utilities actually adds nothing to applicability of a script to different (unknown a priory) environments. On the contrary — it can rather break things. signature.asc Description: PGP signature
Re: "shell-expand-line" wrongly(?) expanded $'foo' to $foo
Clark Wang wrote: > # echo $'foo'# press ESC C-e > # echo $foo + the same with $"foo". signature.asc Description: PGP signature
