Re: Bad substitution when pressing [TAB]
On 9/27/16 4:46 PM, Valentin Bajrami wrote:
> HI,
>
> While I was testing some variable substitution I came across this error /
> unwanted behavior.
>
> So for example:
>
> $ printf '%s' "${/debash: ${/: bad substitution
> bash: ${/: bad substitution
>
> just after printf '%s' "${/[TAB] this behavior is triggert.
Thanks for the report. Bash can avoid the error messages on an incomplete
word expansion, such as the one in your example.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Verbose error output in interactive mode
On 8/5/16 11:16 AM, John Passaro wrote: > Bash Version: 4.3 > Patch Level: 42 > Release Status: release > > Description: > In an interactive session, when attempting file completion via > when a certain type of ill-formed command substitution is present, bash > gives verbose error output relating to "unexpected end of file". > > Naturally you can work around this by never making this mistake when > using command substitution, but it seems to me bash can probably guard > for this and avoid disruptive error messages. Thanks for the report. Bash can avoid the error messages on an incomplete word expansion, such as the one in your example. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Racing condition leads to unstable exit code
On 9/23/16 3:04 PM, Luiz Angelo Daros de Luca wrote: > Hello, > > I'm using 'GNU bash, version 4.3.46(1)-release (x86_64-suse-linux-gnu)' > provided by OpenSUSE Tumbleweed. I recently faced a problem that, depending > on the system load, bash returns different exit codes. I detected that it > is related to trap processing. Thanks for the report. It is related (indirectly) to trap processing in that traps get processed while reading the command substitution output. The problem still exists in bash-4.4, and I will probably release a bash-4.4 patch to address it. There are a few things ahead of that in the queue, though. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Racing condition leads to unstable exit code
No problem! I already workarounded it using pipe as a semaphore. Thanks! It's there any chance of changing the 128+signal exit code for wait when trap is received? It might solve some special usecase which I'm not aware. Wait should always returns exit code related to the child process, except for 127. The 128+signal behavior is not even mentioned on wait documentation but on signal section! If wait returns 129, I don't know wether child died because of signal 1 (128+1) or if it is the current instance that received the signal instead. The worse is that I cannot even trap this signal as wait has precedence. And all depends on timing, if received before wait (which trap takes care) of after it returning the wait call. I think that using wait for catching signals is somehow abusing it, specially when comparing with wait (2) call. Regards, Thanks! Em qui, 29 de set de 2016 16:39, Chet Ramey escreveu: > On 9/23/16 3:04 PM, Luiz Angelo Daros de Luca wrote: > > Hello, > > > > I'm using 'GNU bash, version 4.3.46(1)-release (x86_64-suse-linux-gnu)' > > provided by OpenSUSE Tumbleweed. I recently faced a problem that, > depending > > on the system load, bash returns different exit codes. I detected that it > > is related to trap processing. > > Thanks for the report. It is related (indirectly) to trap processing in > that traps get processed while reading the command substitution output. > The problem still exists in bash-4.4, and I will probably release a > bash-4.4 patch to address it. There are a few things ahead of that in > the queue, though. > > Chet > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ > -- Luiz Angelo Daros de Luca luizl...@gmail.com
Command substitution optimisation in dot scripts
I detected an oddity (possible bug) in bash: the usual optimisation for launching external processes in simple command substitutions is turned off while executing a dot script. Background: For reasons that would take too much space to explain here, I need a cross-platform/POSIX way to get the process ID of the current subshell. I can't use $BASHPID for this as it's only available on newer bash (not including the default bash on Mac OS X). As far as I know, the canonical cross-platform way of detecting the PID of a subshell is: my_subshell_pid=$(sh -c 'echo $PPID') This works fine on every shell, except on bash when a dot script is being executed. This can be tested as follows: ( my_subshell_pid=$(sh -c 'echo $PPID') && echo "PID of this subshell is: $my_subshell_pid" && echo "\$BASHPID is: $BASHPID" && trap 'echo "Correctly terminated"; exit 0' TERM && kill -s TERM "$my_subshell_pid" ) This works fine on bash if executed normally or in a normal shell script: $ bash test.sh PID of this subshell is: 87562 $BASHPID is: 87562 Correctly terminated But if you source it as a dot script (using '.' or 'source') from the bash command line or another bash script, the cross-platform method fails to get the correct subshell PID: $ source test.sh PID of this subshell is: 87551 $BASHPID is: 87550 bash: kill: (87551) - No such process The PID obtained by the cross-platform method is off by one. My educated (?) guess is that an extra bash subshell process is unnecessarily forked just to launch the external 'sh' command. If that is the case, then this adversely affects the performance of dot scripts in bash, which is why I thought it seems worth reporting here. Behaviour confirmed on bash-2.05b (Mac), bash-3.2.57 (Mac), bash-4.1.17 (Linux), bash-4.2.53 (Linux), and bash-4.4.0 (Mac). Thanks, - M.
