Spaces in args, escapes, and command substitution
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables" uname output: Linux XXX.zacglen.com 2.6.14-1.1644_FC4 #1 Wed Feb 22 11:11:16 EST 2006 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.0 Patch Level: 16 Release Status: release Description: Inconsistent handling of escapes in command substitution. Repeat-By: 1. echo `echo a\\ b` 2. echo $(echo a \\ b) In case 1) the result is plain "a b" (both escapes discarded) In case 2) the result is "a\ b" (the space is has single escape) Fix: Can some attention be given to the problem of spaces in file names please? For example, "vi `grep -l *.c`" is fine so long as there are no spaces in the *.c filenames. But if there are, then the split on space that command subsitution does messes everything up. Given that "grep -l" outputs newline-delimited result then surely there should it should be possibly to have the spaces on each line escaped and only the newlines converted to spaces. Perhaps quoted "$(command)" should properly escape spaces before converting newline to space, a little like quoted "$*" does. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
> >> For example, "vi `grep -l *.c`" is fine so long as there are no spaces >> in the *.c filenames. But if there are, then the split on space >> that command subsitution does messes everything up. >> >> Given that "grep -l" outputs newline-delimited result then surely there >> should it should be possibly to have the spaces on each line escaped >> and only the newlines converted to spaces. > >Word splitting is controlled by IFS. Use IFS=$'\n' to only split on >newlines. Tried that. Doesn't work. Perhaps instead of just saying "Use IFS..." you could show me a working example. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
> >Word splitting is controlled by IFS. Use IFS=$'\n' to only split on >newlines. > >Andreas. Well, I still dont see any examples. I don't think it is possible even using IFS. Even if it does work somehow, it isn't easy or intuitive. But there is worse. Try and run the following script: --- f1="/a/b/a-000" f2="/a/b/c d-000" touch "a-000.ext" touch "c d-000.ext" for file in "$(basename \"$f1\")"*.ext "$(basename \"$f2\")"*.ext do echo "one=$file" done for file in "`basename \"$f1\"`"*.ext "`basename \"$f2\"`"*.ext do echo "two=$file" done --- The backticks work perfectly. But the $() gets it very wrong and leaves a double-quote in the result. The two methods should be exactly equivalent when there is no nesting. Regards bahser ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
> >According to [EMAIL PROTECTED] on 10/28/2006 9:42 PM: >> f1="/a/b/a-000" >> f2="/a/b/c d-000" >> touch "a-000.ext" >> touch "c d-000.ext" >> >> for file in "$(basename \"$f1\")"*.ext "$(basename \"$f2\")"*.ext >> do >> echo "one=$file" >> done >> >> for file in "`basename \"$f1\"`"*.ext "`basename \"$f2\"`"*.ext >> do >> echo "two=$file" >> done >> --- >> >> The backticks work perfectly. >> But the $() gets it very wrong and leaves a double-quote in the result. > >That's because `` and $() have different syntax, as required by POSIX. >You should just do $(basename "$f1"), rather than $(basename \"$f1\"). > That's crazy! You have nested double quotes which don't need escaping?! Let me think aloud: The first thing one encounters left-to-right is a double-quote. So, logic says that the quoted string is terminated by matching double-quote. Ok, so that means that the above is: "$(basename " followed by: $f1 followed by: ")" which means that any spaces in $f1 are apparently unquoted and will therefore be subject to arg splitting. Therefore, there must be appropriate kludges in bash which make it work, despite the way in which it defies commonsense. Looks like POSIX and commonsense are two different things. Regards Bahser ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
>Like it or not, POSIX standardized the original bourne shell `` behavior, >as well as the ksh $() behavior, and the two behaviors are different. Get >used to it. Well, thank you for telling me to "get used to it". But I do not generally obey unreasonable commands. Now, please tell me how I can edit a bunch of grep'ed files with spaces in their names, as in "vi `grep -l xxx *.txt`" If I can use IFS then please give an example. If you can quote POSIX etc and give an authoritive answer to all things that matter then surely it wont be too difficult? Regards Bahser _______ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
> >It is unfortunate that your choice of editor does not accept zero >terminated strings as filenames because then this would be easy using >grep's --null option. The problem therefore as I see it is a >deficiency in the editor capabilities. > Oh, so all applications should be adjusted to account for bash/POSIX deficiencies? No. >This is probably not a an optimal solution because this is late night >time for me but this works: > > eval vi $(grep -l PATTERN * | sed 's/ /\\ /') > Yes, that works. But surely such a grotesque syntax is not really in the spirit of concise unix expressions. >I would suggest xargs but the input is not attached to the terminal in >that case. I think xargs has recently been enhanced to allow this but >it is not in most versions. But batch editing works well. > > grep --null -l PATTERN * | xargs -r0 sed --in-place 's/foo/bar/' > Again, one really wants to be able to use normal and concise expressions. >Although having spaces in filenames may be common in some cultures it >is definitely not in the Unix culture. Well, can I also say that unicode and grotesque multi-byte and multi-lingual character sets weren't in the unix culture either. But that is never an excuse. >Being able to work with file >names with spaces is definitely an afterthought. It is best to avoid >them. > > rename 's/ /_/g' * > No! Often filenames must match some scheme, and arbitarily renaming is not a good idea. For example, suppose they are target of html href. Suppose they are target of database reference. Excuse me - but really somebody should sit down and think very hard about this problem and come up with better working system, rather than just excuses. There is a specific challenge here. Something is sort-of broken and needs a good solution. Why is it that word splitting never makes a distinction between newlines and space? Because the output of grep -l, and ls, etc are clearly newline delimited. It is bash (and others) which quite deliberately reduce available information by converting all newlines and whitespace into a single space. Something simple like "vi $(^grep -l xx *)" would do. The ^ might work because it denotes line-orientated regex (and nobody uses it for pipes any more). The ball is quite clearly in bash's court. Regards Bahser ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
>> This is probably not a an optimal solution because this is late night
>> time for me but this works:
>>
>> eval vi $(grep -l PATTERN * | sed 's/ /\\ /')
>
>This also works.
>
> find . -exec grep -q PATTERN {} \; -exec vi {} \;
>
No it doesn't because it issues a fresh instance of vi per file.
Not very good when you create macros and want to apply to
a set of files. Also, vi lets you navigate throught the set of
files in any order ... not possible when separate instances.
Also, find *.c would be a little more appropriate wouldn't it?
But then why not just:
grep -l PATTERN *.c | while read f; do vi "$f"; done
This is a bash mailing list isn't it!
Regards
Bahser
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
>According to [EMAIL PROTECTED] on 10/29/2006 5:56 AM:
>>> This also works.
>>>
>>> find . -exec grep -q PATTERN {} \; -exec vi {} \;
>>>
>>
>> No it doesn't because it issues a fresh instance of vi per file.
>
>Then use the POSIX-specified:
>find . -exec grep -q PATTERN {} \; -exec vi {} +
>
>That will execute grep once per file, then aggregate the successful
>matches into a single invocation of vi (assuming you don't exceed ARG_MAX
>limits), properly accounting for spaces in filenames.
>
But, given that find is clever enough to assemble arguments containing
spaces into an arglist and feeding them to vi, why can't bash?
Regards
Bahser
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
> >According to [EMAIL PROTECTED] on 10/29/2006 3:39 AM: >> Why is it that word splitting never makes a distinction between >> newlines and space? > >Because POSIX, and tradition, say so. > >> Because the output of grep -l, and ls, etc are >> clearly newline delimited. > >That is a flawed argument. Filenames can contain newlines. That is an even more flawed response. In practice how many such filenames have you every come across. I have come across 0, nil, none. Besides, a newline need only be treated like any other non-printing character. It would hardly be sensible to have something that occurs 0.0001% of the time dictate policy for what might occur >1% of the time. >The only SAFE >way to pass arbitrary filenames is null-delimited, if you are truly >worried about metacharacters in the name. That is not SAFE and not a good idea. You cannot easily process such a set with a text editor, sed, tr, etc. It flies right in the face of what Unix is supposed to be about. >True, spaces are more common >than newlines, but if you are going for safety, then go all the way. I think usability is about 1000 times more important than safety, especially when using the term "safe" is used in such a loose and non-specific way. i > >> It is bash (and others) which quite deliberately >> reduce available information by converting all newlines and whitespace >> into a single space. > >Only when told to do so by IFS on underquoted variable expansions and >process substitutions. I am still waiting for somebody to show how IFS can be used to solve this problem. > >> >> Something simple like "vi $(^grep -l xx *)" would do. >> The ^ might work because it denotes line-orientated regex (and nobody >> uses it for pipes any more). > >Actually, that is well-defined by POSIX to invoke the command '^grep'. If >you are going to propose a new operator, you had better choose one that >POSIX leaves unspecified. But you are correct that no one uses ^ for >pipes any more - POSIX does not allow ^ to mean pipes. > I am sure you get my meaning. Just a matter of finding the right character and/or syntax. BTW which comes first - innovation or POSIX mandate? Regards Bahser ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
>Oh, for pete's sake. Take a systematic approach, as Andreas suggested. >First, arrange for the filenames you want to be delimited by newlines. >Since this is for your own use, and you can more-or-less guarantee that >there will never be a newline in a filename, that's sufficient. Second, >arrange things so that the shell won't split words on anything but >newline, your desired delimiter. > >Take a look at the approach in the following example script. `recho' is >part of the bash distribution; it's built while running the test suite. >I used `ls -1' to create a newline-delimited list of filenames. > >$ cat x3 >[ -d scratch ] || mkdir scratch >cd scratch >touch 'a b w' 'c d x' 'e f y' 'g h z' > >IFS=$'\n' >recho $(ls -1 *) >$ ../bash-3.2/bash ./x3 >argv[1] = >argv[2] = >argv[3] = >argv[4] = > Easier is just: ls -1 * Why not give an example which effectively does "vi `grep -l PATTERN *`"? Your example isn't of any use. There isn't any problem with passing spaces in args except when backticks or $() are involved. Bahser ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
>>> $ cat x3 >>> [ -d scratch ] || mkdir scratch >>> cd scratch >>> touch 'a b w' 'c d x' 'e f y' 'g h z' >>> >>> IFS=$'\n' >>> recho $(ls -1 *) >>> $ ../bash-3.2/bash ./x3 >>> argv[1] = >>> argv[2] = >>> argv[3] = >>> argv[4] = >>> >> >> Easier is just: >> >> ls -1 * >> >> Why not give an example which effectively does "vi `grep -l PATTERN *`"? >> Your example isn't of any use. > >OK, one last try. Replace `recho' with `vi', and `ls -1' with >`grep -l PATTERN'. Then take a deep breath and think about what >the output of `recho' says about how the output of the command >substitution was split. I took a very deep breath and did this from command line: IFS='\n' vi $(grep -l PATTERN *) and guess what - it does not work! Please try and focus on the specific problem I have given. I know it can be difficult but give it a go. Regards Bahser ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
>According to [EMAIL PROTECTED] on 10/29/2006 4:52 PM: >> >> I took a very deep breath and did this from command line: >> >> IFS='\n' vi $(grep -l PATTERN *) >> >> and guess what - it does not work! > >That's because you set IFS for the vi, but not for the command >substitution. Break your result into two commands: > >IFS='\n' >vi $(grep -l PATTERN *) > But dont variables set on command line apply to everything on that line? ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
> >That's because you set IFS for the vi, but not for the command >substitution. Break your result into two commands: > >IFS='\n' >vi $(grep -l PATTERN *) > So the IFS setting takes effect immediately after it is seen? So a newline is needed? I would have hoped that the IFS was interpreted after its delimiter has been encountered, so that the single line example would work. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
>That's because you set IFS for the vi, but not for the command >substitution. Break your result into two commands: > >IFS='\n' >vi $(grep -l PATTERN *) > But also, if IFS is what it is supposed to be, wouldn't the correct syntax be: IFS='\n' vi $(grep -l PATTERN *) Or is IFS not really an IFS? ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
> >In other words, IFS only affects the results of expansions, not literal >text; words, in the sense of the shell grammar, are always delineated by >unquoted space, tab, and newline, regardless of the IFS setting. > Thanks for an excellent explanation. But maybe IFS really should have been named EFS? Anyhow I see that bash has taken the liberty of changing the traditional acronym expansion from "Input Field Separator" to "Internal Field Separator". A subtle difference. But the word "Internal" isn't quite as good as "Expansion". Anyhow, it is a pity that something like: vi $(IFS=\n grep -l PATTERN *) or IFS=\n vi $(grep -l PATTERN *) doesn't work. It looks like it should work. Also it might also be more convenient for aliasing. If it wasn't for the fact that there is an ambiguity regarding multiline command output which consists of a single line then it would be possible to make a permanent distinction between multi-line command output (with args separated by newlines and spaces escaped) and single line output where spaces are not escaped. Regards Bhaser ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
> >Messing with shell syntax is not done lightly. It is too late to change >how `` and $() behave; you will break too many existing scripts. The best >you can do now is learn how they do behave, and code accordingly. > In actual fact most of my scripts (anything over say 30 lines) are usually done in Perl now. So it really isn't a matter of "coding" but more about convenience at interactive command-line. Thanks for your input anyhow. Regards Bahser _______ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Potentially misleading documentation of SECONDS variable
On Wed, Aug 07, 2024 at 01:25:35AM +0900, Koichi Murase wrote:
> is supposed to imply that technically. It says "The number of seconds
> at shell invocation", so the starting time point is considered to have
> only the "second" resolution and doesn't have the subsecond
> resolution. Then, when a value is assigned, the starting time point
> would be updated to the number of "seconds" at the assignment.
>
"seconds" being in quotes here since it is not actually the "number of
seconds" but rather "the time passed truncated to whole-second
resolution". :)
> For example, when the assignment occurs at time X.7, the recorded time
> becomes just X (with the fraction part being truncated). Then, the
> value obtained from SECONDS is incremented when the clock becomes
> (X+1).0. This is consistent with the observed behavior.
>
I agree! It's the truncating part that is the cause of this
confusion.
> However, I agree that this is implicit and ambiguous. A minimal
> modification is probably something like
>
> diff --git a/doc/bash.1 b/doc/bash.1
> index 1f0a23d3..3ace21e9 100644
> --- a/doc/bash.1
> +++ b/doc/bash.1
> @@ -2091,7 +2091,7 @@ the value returned upon subsequent
> references is
> the number of seconds since the assignment plus the value assigned.
> The number of seconds at shell invocation and the current time are always
> -determined by querying the system clock.
> +determined by querying the system clock at the resolution of a second.
> If
> .SM
> .B SECONDS
> diff --git a/doc/bashref.texi b/doc/bashref.texi
> index 510b43f6..6ee0083b 100644
> --- a/doc/bashref.texi
> +++ b/doc/bashref.texi
> @@ -7038,7 +7038,7 @@ Assignment to this variable resets the count to
> the value assigned, and the
> expanded value becomes the value assigned plus the number of seconds
> since the assignment.
> The number of seconds at shell invocation and the current time are always
> -determined by querying the system clock.
> +determined by querying the system clock at the resolution of a second.
> If @env{SECONDS}
> is unset, it loses its special properties,
> even if it is subsequently reset.
>
Ideally, I would have it stating something about the possible
discrepancy due to truncating the underlaying, higher resolution value.
Maybe something like:
" +determined by querying the system clock, disregarding any subsecond
portion of the system clock value"
Such information would have helped me understand what is happening, at
least :)
Re: Potentially misleading documentation of SECONDS variable
On Tue, Aug 06, 2024 at 03:58:35PM -0400, Chet Ramey wrote: > [...] Bash has never looked at > anything but whole seconds. [...] > Ok, cool. So this is not a bug but rather just how Bash works. That's fine but then I think the documentation could reflect the actual behaviour better. I found this "edge case" (where it seemed as if Bash sometimes failed at calculating the correct value) a bit confusing. Maybe I was using Bash in a "non-standard" way, not as it was supposed to... But still, I think the behaviour could be more intuitive. From reading the manual I expected a different behaviour but since I have not coded anything on Bash myself I know I have no right to anything else than an opinion :) > If you're interested in that kind of sub-second precision, use > EPOCHREALTIME. If you want something that's not affected by assignment, > use EPOCHSECONDS. > I am not. I have since this "discovery" learnt to use lower case variable names which solves all and every issue I had before. Opening this issue was merely an attempt to raise the question on if and how Bash could be improved.
[PATCH] fix COMP_WORDS when completing an empty word
From: Naïm Favier
Currently, typing `cmd flag1 flag2` (note the two spaces), navigating
between the two spaces and hitting Tab produces
`COMP_WORDS=(cmd flag1 flag2)` without inserting an empty word between
flag1 and flag2.
I believe this comes from considering the cursor ("sentinel") as a block
rather than a line, which does not make sense in a completion context,
but might possibly make sense in other contexts?
Note that this aligns with the behaviour of the default readline
completion.
Signed-off-by: Naïm Favier
---
subst.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/subst.c b/subst.c
index 2b76256c..f3452517 100644
--- a/subst.c
+++ b/subst.c
@@ -2379,11 +2379,6 @@ split_at_delims (string, slen, delims, sentinel, flags,
nwp, cwp)
if (sentinel >= ts && sentinel <= te)
cw = nw;
- /* If the cursor is at whitespace just before word start, set the
-sentinel word to the current word. */
- if (cwp && cw == -1 && sentinel == ts-1)
- cw = nw;
-
/* If the cursor is at whitespace between two words, make a new, empty
word, add it before (well, after, since the list is in reverse order)
the word we just added, and set the current word to that one. */
--
2.36.1
Re: {varname} for redirection does not work with arrays
On Nov 5, 12:34 pm, Stephane CHAZELAS
wrote:
> 2011-11-2, 12:01(-06), unkn...@vmw-les.eng.vmware.com:
> [...]> Description:
> > If {varname} is an assoc. array in a redirection the exec will fail
> > The [] should not be confused with pathname expansion just like ${}.
>
> > Repeat-By:
> > $ declare -A array
> > $ exec {array[key]}
> [...]
>
> In the documentation, it's {VARNAME} documented.
>
> zsh doesn't support {array[key]}
> ksh does though it's not documented (documented the same as
> bash).
>
> The work around is easy though:
>
> $ declare -A array
> $ exec {var} $ array[key]=$var
>
> --
> Stephane
Hello Stephane,
The workaround is trivial, its just inconsistent (with other parts
of bash).
I can say:
$ declare -A array
$ read -r 'array[key]' <<< 'foo'
This also makes arrays more directly useful.
$ declare -A fd
$ local fifo
$ exec {fifo}<"${fifo_path}"
$ fd[fifo]="${fifo}"
$ unset fifo
becomes
$ declare -A fd
$ exec {fd[fifo]}<"${fifo_path}"
cd ${DIRSTACK[1]} fails on use of ~
Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: darwin9.0
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc' -
DCONF_OSTYPE='darwin9.0' -DCONF_MACHTYPE='powerpc-apple-darwin9.0' -
DCONF_VENDOR='apple' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I/SourceCache/bash/bash-61/
bash -I/SourceCache/bash/bash-61/bash/include -I/SourceCache/bash/
bash-61/bash/lib -I/SourceCache/bash/bash-61/bash/lib/intl -I/private/
var/tmp/bash/bash-61.obj~2/lib/intl -arch i386 -arch ppc -g -Os -
pipe -no-cpp-precomp -mdynamic-no-pic -DM_UNIX -arch i386 -arch ppc -
pipe
uname output: Darwin zardoz.apple.com 9.0.0d1 Darwin Kernel Version
9.0.0d1: Sun Feb 26 17:29:52 PST 2006; root:xnu-848.obj~3/RELEASE_PPC
Power Macintosh
Machine Type: powerpc-apple-darwin9.0
Bash Version: 3.1
Patch Level: 0
Release Status: release
Description:
PR-4458849
if ~ ends up in $DIRSTACK you can't directly cd to ${DIRSTACK[n]}
Repeat-By:
cd /var/tmp
mkdir test
HOME=/var/tmp
cd test
pushd ./
cd ..
cd ${DIRSTACK[1]}
# error from bash
bash: cd: ~/test: No such file or directory
# ktrace shows a stat("/var/tmp/~") failing
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Oddities when tab-completing filenames containing backticks
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux atu 2.6.27-14-generic #1 SMP Mon Aug 31 12:58:38 UTC 2009 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.0 Patch Level: 39 Release Status: release Description: Also affects Bash 4.0.33. When a filename begins with a backtick ` then tab-completion works as expected if you go \`, however if you try to tab-complete the filename inside single quotes, several strange behaviours appear. Repeat-By: 1) '` This causes all commands available on the system to be listed such as `awk `bash etc., even though it's inside single quotes. 2) '`text This completes the filename, but it does not insert a trailing single quote as tab-completion would usually do. 3) '`dir This completes the directory name and adds the trailing forward slash, but not the trailing single quote. 4) 'text` This completes the filename and closes the single quote as expected. 5) '`text' When using tab-completion inside single quotes on a filename beginning with a backtick, then it completes the filename and adds an additional closing single quote, e.g. '`filename.txt'' 6) '`dir' When using tab-completion inside single quotes on a directory name beginning with a backtick, then it completes the directory name and adds an additional closing single quote after the directory name and before the forward slash, e.g. '`directory'/'
Re: Oddities when tab-completing filenames containing backticks
2009/10/16 Chet Ramey : > You need to remember that readline understands the characters in > rl_completer_quote_characters as those which, in pairs, delimit quoted > substrings in the line. It performs completion (allowing the application > to take first crack, of course) on the substring, using the text after > the open quote. Then it is a bug in readline that it is incapable of properly handling nested quotes. > The other thing to keep in mind is that readline doesn't look past point > when performing completion -- it only considers characters from the > beginning of the line or a quote character up to point. If it considered characters from the beginning of the line, then there would be no issue. The backtick is inside an open single quote, and the backtick is *not* a special character under that circumstance -- it's no more special to Bash than the letter "j" inside an open single quote. > My answers below are for the built-in bash completion, not > any programmable completions you might have defined. I don't use any programmable completion, these are all stock, and confirmed by other users of irc://irc.freenode.net/#bash >> Repeat-By: >> >>1) '` This causes all commands available on the system to be >>listed such as `awk `bash etc., even though it's inside >> single quotes. > > Readline does completion on substrings; it passes ` to the bash completion > code, which performs command completion. Again, a backtick is no more of a special character than the letter "a" inside an open single quote. This is incorrect behaviour. >>2) '`text This completes the filename, but it does not insert a >>trailing single quote as tab-completion would usually do. > > Bash receives "`text" What do you mean by that? Didn't you say Bash is sending that to readline? > does command completion on `text' How would it do completion on something that isn't there? I did not fill in a closing single quote. > and suppresses the append of the close quote, > since it's usually wrong in this case. What appended closing quote, there is none? If you go: # ls '/usr/bin/mpg3 You get the following: # ls '/usr/bin/mpg321' But if you have a file called /tmp/`rubble.txt and go: # ls '/tmp/`rub Then you get: # ls '/tmp/`rubble.txt No closing single quote. Incorrect and inconsistent behaviour. Inside single quotes, a backtick is no different from any other character allowed in filenames, including control characters, tabs, newlines, accented letters, line-drawing characters, dashes, exclamation points, etc. Another example: # ls '/tmp/!rub Completes as expected with the closing single quote for: # ls '/tmp/!rubble.txt' The same goes for these filenames: # ls '/tmp/~test.txt' # ls '/tmp/"test.txt' # ls '/tmp/$test.txt' # ls '/tmp/-test.txt' # ls '/tmp/(test.txt' # ls '/tmp/&test.txt' They all close the single quote. The only one that messes up is the filename beginning with a backtick. >>3) '`dir This completes the directory name and adds the trailing >>forward slash, but not the trailing single quote. > > Again, appending the trailing single quote without the trailing ` is > generally going to be wrong. Please explain yourself. Backticks *are not special* inside single quotes. Do you need a closing "h" if you have an opening "h" in "hello world"? No? Then why would you need a closing backtick which is just another normal character? This is obviously incorrect behaviour. >>4) 'text` This completes the filename and closes the single quote >>as expected. > > Interesting. I don't get this behavior. This behaviour makes snese, because it is the correct behaviour. The other behaviour above is the incorrect behaviour. A backtick is *not* special to Bash from inside single quotes. >>5) '`text' When using tab-completion inside single quotes on a >>filename beginning with a backtick, then it completes >>the filename and adds an additional closing single quote, >>e.g. '`filename.txt'' > > Also interesting. I get normal command completion without any closing > quote appended. Are you following my example exactly? I'll provide exact steps to reproduce, below. Step 1: touch '/tmp/`example.txt' Step 2: ls '/tmp/`exam' Step 3: Place your cursor on top of the closing single quote, after the "m", and press Result:
Returned due to virus; was:Mail Delivery (failure [EMAIL PROTECTED])
Title: VIRUS INFECTION ALERT VIRUS INFECTION ALERT The WebShield® e1000 Appliance discovered a virus in this file. The file was not cleaned and has been removed. See your system administrator for further information. File name: noname.htm Virus name: Exploit-MIME.gen.c Copyright © 1993-2003, Networks Associates Technology, Inc. All Rights Reserved. http://www.mcafeeb2b.com Title: VIRUS INFECTION ALERT VIRUS INFECTION ALERT The WebShield® e1000 Appliance discovered a virus in this file. The file was not cleaned and has been removed. See your system administrator for further information. File name: message.scr Virus name: W32/[EMAIL PROTECTED] Copyright © 1993-2003, Networks Associates Technology, Inc. All Rights Reserved. http://www.mcafeeb2b.com ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Returned due to virus; was:Mail Delivery failure ([EMAIL PROTECTED])
Title: VIRUS INFECTION ALERT VIRUS INFECTION ALERT The WebShield® e1000 Appliance discovered a virus in this file. The file was not cleaned and has been removed. See your system administrator for further information. File name: noname.htm Virus name: Exploit-MIME.gen.c Copyright © 1993-2003, Networks Associates Technology, Inc. All Rights Reserved. http://www.mcafeeb2b.com Title: VIRUS INFECTION ALERT VIRUS INFECTION ALERT The WebShield® e1000 Appliance discovered a virus in this file. The file was not cleaned and has been removed. See your system administrator for further information. File name: message.pif Virus name: W32/[EMAIL PROTECTED] Copyright © 1993-2003, Networks Associates Technology, Inc. All Rights Reserved. http://www.mcafeeb2b.com ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
(no subject)
___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash doesn't compile when configured with --disable-bang-history
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I/scratch/bash-3.0 -I/scratch/bash-3.0/include -I/scratch/bash-3.0/lib uname output: Linux noname 2.0.40-rc6 #2 Fri May 9 10:34:15 MSZ 2003 i686 unknown unknown GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.0 Patch Level: 0 Release Status: release Description: It is not possible to selectively disable the history expansion with --disable-bang-history Repeat-By: ./configure --disable-bang-history make Fix: Fix the Conditions for BANG_HISTORY in variables.h and variables.c in a sensible way ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
building: recutils bash builtins/readrec.so; ./configure --with-bash-headers=... # fails
No response today from bug-recutils: http://lists.gnu.org/archive/html/bug-recutils/2017-11/msg4.html For the ./configure, I untarred the latest bash source into a subdir, and set --with-bash-headers= to that pathname. Perhaps someone with an understanding of GNU configure/autoconf etc could take a look and give me some hints. Or tell me where to ask. -- thanks!
bash sockets: printf \x0a does TCP fragmentation
Hello there, we discovered a strange phenomenon in the project testssl.sh: After opening a TCP socket with a fd (here: 5), when writing to it, it seems that printf -- "$data" >&5 2>/dev/null does not do what it is intended. "$data" is a ClientHello like '\x16\x03\x01\x2\x00\x01\x00\x1\xfc\x03\x03\x54\x51\x1e\x7a\xde\xad\xbe\xef\x31\x33\x07\x00\x00\x00\x00\x00\xcf\xbd\x39\x04\xcc\x16\x0a\...' Each \x0a like the last one causes a new TCP fragment to begin which can be easily spotted when using wireshark while running e.g. testssl.sh --assume-http -p testssl.sh Starting from the SSLv3 ClientHello the first reassembled packet ends with 0a. See also discussion @ https://github.com/drwetter/testssl.sh/pull/1113. One would assume that a bash socket connection cannot influence the TCP fragmentation but obviously it does. This behavior has a performance penalty and other strange effects, e.g. if the first segment is really small, some devices reject the ClientHello. If there's a workaround, please let me know. (tried to add "%b" with no effect). Otherwise I believe it's a bug. Cheers, Dirk PS: Would ulimit -b help?
Re: bash sockets: printf \x0a does TCP fragmentation
On 9/22/18 1:34 AM, Chet Ramey wrote: > On 9/21/18 4:13 PM, dirk+b...@testssl.sh wrote: >> >> Hello there, >> >> we discovered a strange phenomenon in the project testssl.sh: >> >> After opening a TCP socket with a fd (here: 5), when writing to it, >> it seems that >> >> printf -- "$data" >&5 2>/dev/null >> >> does not do what it is intended. "$data" is a ClientHello like >> >> '\x16\x03\x01\x2\x00\x01\x00\x1\xfc\x03\x03\x54\x51\x1e\x7a\xde\xad\xbe\xef\x31\x33\x07\x00\x00\x00\x00\x00\xcf\xbd\x39\x04\xcc\x16\x0a\...' >> >> Each \x0a like the last one causes a new TCP fragment to begin which can be >> easily >> spotted when using wireshark while running e.g. > > Newline? It's probably that stdout is line-buffered and the newline causes > a flush, which results in a write(2). Anything one can do on the level of bash or non-syscall land? What about ulimit -b ? >> If there's a workaround, please let me know. (tried to add "%b" with no >> effect). Otherwise I believe it's a bug. > > How? Does the emitted output not correspond to what's passed to printf > in some way? "\x0a" is a legitimate byte which is send from time to time over the socket. It happens if the record layer is e.g. 522 bytes (\x02\x0a), if a standard cipher is included in the handshake like (\xc0\x0a) or DES-CBC3-SHA (\x00\x0a) ECDHE-ECDSA-AES256-SHA or at any other occasion. Everything works as expected and like a charm for years now -- the only thing isthe underlying TCP fragmentation which is caused as a side effect by sending \x0a. As indicated a few servers under certain condition can't cope with it asif the TCP first segment is too small they don't treat this as ClientHello and just drop the packet, see thread @ https://github.com/drwetter/testssl.sh/pull/1113, specifically the hint wrt https://support.f5.com/csp/article/K53322151 . My stance is simply if I use in the internal feature of bash for TCP socket programming I didn't expect to have side effects like this. Thx, Dirk
Re: bash sockets: printf \x0a does TCP fragmentation
On 9/22/18 7:30 AM, Bob Proulx wrote: > dirk+b...@testssl.sh wrote: >> we discovered a strange phenomenon in the project testssl.sh: > > You are doing something that is quite unusual. You are using a shell > script direction on a TCP socket. That isn't very common. Do you think there should be a paragraph NOT COMMON where bash sockets should rather belong to? > More > typically one would use a C program instead. So it isn't surprising > that you are finding interactions that are not well known. Bob, my intention was not to discuss program languages and what is typical with you or anybody else here. >> printf -- "$data" >&5 2>/dev/null > > Why is stderr discarded? That is almost always bad because it > discards any errors that might occur. You probably shouldn't do this.> > What happens if $data contains % format strings? What happens if the > format contains a sequence such as \c? This looks problematic. This > is not a safe programming proctice. I doubt you can judge on this by just looking at a single line of code -- the project has > 18k LoC in bash. Github is the place to discuss and do PRs for our project. >> If there's a workaround, please let me know. (tried to add "%b" with no >> effect). Otherwise I believe it's a bug. > > You can re-block the output stream using other tools such as 'cat' or > 'dd'. Since you are concerned about block size then perhaps dd is the > better of the two. > > | cat cat has a problem with binary chars, right? And: see below. > Or probably better: > > | dd status=none bs=1M > > Or use whatever block size you wish. The 'dd' program will read the > input into its buffer and then output that block of data all in one > write(2). That seems to be what you are wanting. We actually use dd to read from the socket. Of course we could use writing to it as well -- at a certain point of time. Still, a prerequisite would be that printf is the culprit and not how bash + libs do sockets. > P.S. You can possibly use the 'stdbuf' command to control the output > buffering depending upon the program. > > info stdbuf That could be an option, thanks. Need to check though whether a) it doesn't fragment then -- not sure while reading it b) it's per default available on every platform supported by testssl.sh. Cheers, Dirk
Re: bash sockets: printf \x0a does TCP fragmentation
On 9/22/18 12:38 PM, Ilkka Virta wrote: > On 22.9. 02:34, Chet Ramey wrote: >> Newline? It's probably that stdout is line-buffered and the newline causes >> a flush, which results in a write(2). > > Mostly out of curiosity, what kind of buffering logic does Bash (or the > builtin > printf in particular) use? It doesn't seem to be the usual stdio logic where > you get > line-buffering if printing to a terminal and block buffering otherwise. I get > a > distinct write per line even if the stdout of Bash itself is redirected to say > /dev/null or a pipe: > > $ strace -etrace=write bash -c 'printf "foo\nbar\n"' > /dev/null > write(1, "foo\n", 4) = 4 > write(1, "bar\n", 4) = 4 > +++ exited with 0 +++ Oh. But thanks anyway! coreutils in fact does it in one shot as you indicated. Dirk
Re: bash sockets: printf \x0a does TCP fragmentation
On 9/22/18 12:30 PM, Ilkka Virta wrote: > The coreutils printf seems to output 'foo\nbar\n' as a single write, though > (unless > it goes to the terminal, so the usual stdio buffering), so you might be able > to use > that. thx. Might be not that portable but we'll see. > In any case, if a TCP endpoint cares about getting full data packets within a > single > segment, I'd say it's broken. fully agree. But unfortunately it just comforts us :-) Keep in mind that the purpose of the tool is testing and if due to a bug it can't do that, were the ones being blamed or we need to do really strange workarounds to avoid '\x0a' in the first 8 bytes. Dirk
Re: bash sockets: printf \x0a does TCP fragmentation
On 9/23/18 8:26 PM, Chet Ramey wrote: > On 9/22/18 4:22 PM, Bob Proulx wrote: > >> Note that I *did* provide you with a way to do what you wanted to do. :-) >> >> It was also noted in another message that the external standalone >> printf command line utility did buffer as you desired. That seems >> another very good solution too. Simply use "command printf ..." to >> force using the external version. > > This won't work the way you want. The `command' builtin only inhibits > execution of shell functions. It still executes builtins. You want to > either get the full pathname of a printf utility using `type -ap printf' > and use that, or use the env or exec variants I recommended in my last > message. FYI: I ended up checking with type before whether an external printf exists and set a variable for this and then just call this variable. env or exec: never thought about it (thanks!) but as both are external commands, that would mean upon every call one additional external program. (yes, I know that there is such thing as a fs buffer). Subshells also costs resources. As this is a core function I am happy for every homeopathic dose of time I safe here :-) Cheers, Dirk
Re: bash sockets: printf \x0a does TCP fragmentation
On 9/25/18 3:46 PM, Chet Ramey wrote: > On 9/25/18 9:04 AM, dirk+b...@testssl.sh wrote: > >> FYI: I ended up checking with type before whether an external printf >> exists and set a variable for this and then just call this variable. >> >> env or exec: never thought about it (thanks!) but as both are external >> commands, that would mean upon every call one additional external program. >> (yes, I know that there is such thing as a fs buffer). Subshells also costs >> resources. As this is a core function I am happy for every homeopathic dose >> of time I safe here :-) > > `exec' is a shell builtin. It will `cost' in terms of a fork, but you're > going to fork and exec a different program anyway -- /usr/bin/printf -- > so it's basically a wash. In either case, there's one fork and one > execve. yeah, you're right.
bash 1-liner or function to tee to STDERR in middle of pipe?
This does what I want:
--8<---cut here---start->8---
_tee_stderr ()
{
<<'eohd'
SYNOPSIS
ourname
DESCRIPTION
Use in a pipe. Leaks STDIN to STDERR. Passes STDIN to STDOUT unchanged.
EXAMPLE
$ seq 5 |_tee_stderr |tail -2 > /tmp/bar ; echo;cat /tmp/bar
1
2
3
4
5
4
5
eohd
( tmpf=$( mktemp ~/tmp/$FUNCNAME.XXX );
cat > $tmpf;
cat $tmpf 1>&2;
cat $tmpf;
rm -f $tmpf );
return;
}
--8<---cut here---end--->8---
What is better/cleaner?
--
thanks!
Re: foo | tee /dev/stderr | bar # << thanks!
Hi Lawrence: On Fri 7/3/20 14:03 -0400 =?utf-8?Q?Lawrence_Vel=C3=A1zquez?= wrote: >What's wrong with `foo | tee /dev/stderr | bar`? Perfect! This morning I had thought of foo | tee >(cat >&2) | bar but your soln is simplier. I assume /dev/stderr is on non linux UNIX also. -- thanks-you!, Tom -- $ seq 5 | tee /dev/stderr |tail -2 1 2 3 4 5 4 5
RE: Double quotes do not work in command substitution?
Yes, that's expected. If a command substitution undergoes word splitting, the output will be split on whitespace. If it doesn't (you use the "$(...)" form, with quotes around), the output forms a single word, which will result in 'a b c' as the single value of $k. This will do what you want: $ eval "for k in $(echo \"a b\" c); do echo \$k; done" a b c First the command substitution is performed inside the double quoted string, resulting in eval 'for k in "a b" c; do echo $k; done' being executed. Running scripts with 'set -xv' is helpful in figuring out this sort of thing. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Operator || disables set -e in subshells: Bug or feature?
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux hotel562.server4you.de 2.6.15-27-amd64-xeon #1 SMP PREEMPT Sat Sep 16 02:12:56 UTC 2006 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: Today I recognized a strange behavior of Bash with set -e and operator || (same for && as well). $ bash -ec 'set -e; ( set -e; /bin/false; echo wrong; ) || echo correct' wrong I would expect the output to be "correct", but it is "wrong". The bash comes from Ubuntu 6.06 LTS, however Debian Etch shows the same. Also ksh and zsh reproduce this strange behavior as well, so perhaps it's an undocumented feature? Same is true for "if" constructs: $ bash -ec 'set -e; if ! ( set -e; /bin/false; echo wrong; ); then echo correct; fi' wrong In contrast look at following line: $ bash -ec 'set -e; ( set -e; /bin/false; echo wrong; ); [ 0 = $? ] || echo correct' correct This outputs what I do expect from all above commands to output. Apparently the "||" operator (and "&&" and "if" as well) disable "set -e" within subshell execution. You even cannot re-enable it again! Is it only me who thinks that is very strange? At least this sideeffect *must* be documented somewhere very clearly (manual and help), as it may be crucial to have your commands terminated as soon as they do not return true. However surrounding commands with a sub-shell (which is convenient to PWD-changes or "catch exit" like in the "set -e" case) and then adding some '|| sequence' (or "if") does strange things. Note that this "set -e globally disabled" feature propagates through the complete script within your current shell. If you use any conditional on the command, even with function invocations, you will see this behavior. This means, when it comes to "set -e", there is a fundamental difference if you define some fn within the shell, and invoke "fn;" or "if fn; then ...", as in the first case it is run under "set -e" control, in the latter it isn't. Repeat-By: Following two commands behave strangely IMHO: bash -ec 'set -e; ( set -e; /bin/false; echo wrong; ) || echo correct' bash -ec 'set -e; if ! ( set -e; /bin/false; echo wrong; ); then echo correct; fi' Fix: Abstain from using script function with "if" or other conditionals. Instead check the return code manually, which is very tedious, like in: bash -ec 'set -e; ( set -e; /bin/false; echo wrong; ); [ 0 = $? ] || echo correct' Another "solution" seems to downgrade to Bash2 (taken from an old SuSE-Linux): $ bash --version GNU bash, version 2.05.0(1)-release (i386-suse-linux) Copyright 2000 Free Software Foundation, Inc. $ bash -ec 'set -e; ( set -e; /bin/false; echo wrong; ) || echo correct' correct However note on a very old KSH I can see the considered wrong behavior, too: $ ksh -c 'echo $KSH_VERSION; set -e; ( set -e; /bin/false; echo wrong; ) || echo correct' @(#)PD KSH v5.2.14 99/07/13.2 wrong
file access time and file modification time
Hi,I'm having some difficulties with the file access time and the file modification time. Scripts are attached for your convenience.Regards,Mischa Baars.Sent from my Samsung Galaxy smartphone. conditional.sh Description: application/sh accesstime.sh Description: application/sh
${VAR:4@Q} parameter modifiers don't compose
Variable transforms such as ${VAR@Q} do not compose with substrings
expansions, eg ${VAR:1:4}.
For example, I expected ${VAR:4@Q} to quote ${VAR:4}, but instead:
-bash: VAR: 4@Q: value too great for base (error token is "4@Q")
This is because parameter value modifiers do not compose; generally
a single value modifier is supported per expansion. The
implementation's common parameter processing code assumes
the modifier's handler requires the full text up to the next
closing '}'.
parameter_brace_expand()
{
...
if (c == ':') want_substring=1;
else if (c == '/') want_patsub=1;
else if (c == '^' or ',' or '~') want_casemode=1;
...
/* Get the rest of the stuff inside the braces. */
if (c && c != RBRACE)
{
value = extract_dollar_brace_string(string,
&sindex, quoted, SX_POSIXEXP | SX_WORD);
}
...
if (want_substring)
{ parameter_brace_substring(,value,); return; }
else if (want_patsub)
{ parameter_brace_patsub(,value,); return; }
else if (want_casemod)
{ parameter_brace_casemod(,value,); return; }
switch (c)
{
case '@':
parameter_brace_transform(,value,); return;
}
}
I have been thinking of a general extension that allows composition
of parameter value modifiers without changing current parsing.
It looks like this:
${VAR{:4}{@Q}^}
The intuitive rule here is that if a normally-terminal modifier
is placed in braces, then it may precede another or a subsequent
final unbraced modifier. Braced operands are constrained to the
next closing brace without ambiguity.
Thoughts?
[patch] mkinitcpio segfaults sometimes (with bash 'devel', but not with bash 5.0.007)
please see patch(and info) in
https://gist.github.com/howaboutsynergy/3e7237a53dbd102f821650b97b9bde57#gistcomment-2961148
(patch also attached)
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -pipe -march=native -Wno-trigraphs -fno-schedule-insns2
-fno-delete-null-pointer-checks -mtune=native -fomit-frame-pointer -O2
-D_FORTIFY_SOURCE=2
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
-fstack-protector-strong -fno-omit-frame-pointer -ftrack-macro-expansion=2
-ggdb -fvar-tracking-assignments -O0 -Wno-parentheses -Wno-format-security
uname output: Linux i87k 5.2.0-rc7-g6fbc7275c7a9 #15 SMP Wed Jul 3 00:43:14
CEST 2019 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 7
Release Status: maint
all other details got lost when I answered 'n' to:
Send bug report to bug-bash@gnu.org? [y/n]
(and I don't feel like typing all that again)
but all you need to know is already in that gist comment anyway
thanks.diff --git a/jobs.c b/jobs.c
index d81bc238..7756406f 100644
--- a/jobs.c
+++ b/jobs.c
@@ -2499,10 +2499,22 @@ wait_for_background_pids (ps)
}
#if defined (PROCESS_SUBSTITUTION)
- if (last_procsub_child && last_procsub_child->pid != NO_PID && last_procsub_child->pid == last_asynchronous_pid)
+ if (last_procsub_child && last_procsub_child->pid != NO_PID)
r = wait_for (last_procsub_child->pid);
wait_procsubs ();
reap_procsubs ();
+#if 0
+ /* We don't want to wait indefinitely if we have stopped children. */
+ if (any_stopped == 0)
+{
+ /* Check whether or not we have any unreaped children. */
+ while ((r = wait_for (ANY_PID)) >= 0)
+ {
+ QUIT;
+ CHECK_WAIT_INTR;
+ }
+}
+#endif
#endif
/* POSIX.2 says the shell can discard the statuses of all completed jobs if
@@ -3695,10 +3707,8 @@ itrace("waitchld: waitpid returns %d block = %d children_exited = %d", pid, bloc
/* Only manipulate the list of process substitutions while SIGCHLD
is blocked. */
if ((ind = find_procsub_child (pid)) >= 0)
- {
- set_procsub_status (ind, pid, WSTATUS (status));
- bgp_add (pid, WSTATUS (status));
- }
+ set_procsub_status (ind, pid, WSTATUS (status));
+ /* XXX - save in bgpids list? */
#endif
/* It is not an error to have a child terminate that we did
publickey - howaboutsynergy@protonmail.com - 0x947B9B34.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Suggestion that might help clarify meaning
Hi, I've been searching the BASH manual ( https://www.gnu.org/software/bash/manual/bash.html) to find out about the precedence/sequence that the shell parses commands. The particular question I've had which I was helped with: https://unix.stackexchange.com/questions/526646/precedence-of-subshells-in-relation-to-redirection . May I request a slight edit in the sentence from section 3.7.1 Simple Command Expansion: "When a simple command is executed, the shell performs the following expansions, assignments, and redirections, from left to right. " to something like: "When a simple command is executed, the shell performs the following expansions, assignments, and redirections, from left to right, in the following sequence." or "When a simple command is executed, the shell performs the following expansions, assignments, and redirections, from left to right, with the following precedence. " As this makes it a bit more explicit that the following list gives a sequence/precedence that tells us the order in which commands are parsed. The intended meaning wasn't fully clear to me upon first reading and I believe that this would make the documentation more readable and might prevent cases of similar confusion. Best wishes, Gavin Rebeiro
seg fault after interrupting time of shell function
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/build/bash-GTWdCm/bash-4.4.18=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux .google.com -amd64 #1 SMP Debian
(2019-05-15 > 2018) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4
Patch Level: 19
Release Status: release
Description:
I found a reproducible segmentation fault in bash.
Some interaction between the "time" builtin and signals, perhaps?
The stack trace for this crash (with addresses elided) was:
#0 ... in _int_malloc (av=av@entry=... , bytes=bytes@entry=32)
at malloc.c:...
#1 ... in __GI___libc_malloc (bytes=32) at malloc.c:...
#2 ... in xmalloc ()
#3 ... in unwind_protect_mem ()
#4 ... in ?? ()
#5 ... in ?? ()
#6 ... in execute_command_internal ()
#7 ... in execute_command ()
#8 ... in reader_loop ()
#9 ... in main ()
Repeat-By:
1. Start a bash shell, and type the following commands:
foo() { sleep 10; sleep 10; }
bar() { time foo; }
bar
2. Interrupt the command in step 1 by hitting control-C after "bar" has
been running for a second or two.
3. Type the following commands:
bar
Terminal log from reproducing this bug:
bash$ env - bash --noprofile --norc
bash-4.4$ ulimit -c unlimited
bash-4.4$ cd /tmp
bash-4.4$ foo() { sleep 10; sleep 10; }
bash-4.4$ bar() { time foo; }
bash-4.4$ bar
^C
real0m0.832s
user0m0.002s
sys 0m0.001s
bash-4.4$ bar
Segmentation fault (core dumped)
--
Fergus Henderson
Potentially misleading documentation of SECONDS variable
Reading the manual at <https://www.gnu.org/software/bash/manual/bash.html#Bash-Variables> regarding the SECONDS variable, it states that " [..] Assignment to this variable resets the count to the value assigned, and the expanded value becomes the value assigned plus the number of seconds since the assignment. [..]" This implies that assigning the variable at time X with value Y would reset SECONDS to Y. When expanding the variable at time X+Z the value should be Y+Z. The text also implies whole seconds, i.e. not milliseconds or other fractions of seconds, are considered. However, it would seem as if the underlying mechanism to update SECONDS (the system clock) are actually considering fractions of seconds and not whole seconds. Below is a small programming that shows my point: #!/bin/bash while true; do SECONDS=0 sleep 0.5 if [ "$SECONDS" != "0" ]; then printf 'This is unexpected: %s != 0\n' "$SECONDS" fi done As we sleep less than a full second the expanded value of SECONDS should never be greater than 0 but it sometimes is. I guess this is because the assignment might occur, say X.7 seconds and the expanded value will then read (X+1).2 which would be rounded down to (X+1). This might not be a bug but it is at least misleading when reading the documentation and produces unexpected and inconsistent behaviour in some cases. Version of Bash used to test this behaviour: GNU bash, version 5.2.32(1)-release (x86_64-pc-linux-gnu)
