multiline ^C regression
Hi, Type a multiline command, and press ^C. bash-4.2: The new prompt appeared below the complete multiline command. bash-4.3: The new prompt appears right under the previous prompt, overwriting parts of the aborted command line and leaving garbage after the new prompt. I believe this is a regression, at least it's very inconvenient for me. I often bring back an older command for having it displayed on the screen, to use it as a reference to type a new command, or to copy-paste parts of it. I don't mean to execute it, hence I press ^C, yet I'd like it to remain displayed on the screen. I hope the change in the behavior was not intended and I'd be glad if you could please fix it :) Thanks in advance, egmont
Re: multiline ^C regression
Egmont Koblinger writes: > Type a multiline command, and press ^C. > > bash-4.2: The new prompt appeared below the complete multiline command. > > bash-4.3: The new prompt appears right under the previous prompt, > overwriting parts of the aborted command line and leaving garbage after the > new prompt. Cannot reproduce: chris@lakes:~$ while : > do > : > : > :^C chris@lakes:~$ echo $BASH_VERSION 4.3.0(1)-release Does this happen when you execute bash without sourcing the profile/rc? pgpK34IskcEjm.pgp Description: PGP signature
Re: multiline ^C regression
Sorry, I wasn't clear enough. By "multiline" I mean a simple command that is so long (e.g. takes so many parameters) that it cannot fit into a single line. (You reach the right margin of your terminal and keep on typing.) On Thu, Mar 27, 2014 at 8:50 AM, Chris Down wrote: > Egmont Koblinger writes: > > Type a multiline command, and press ^C. > > > > bash-4.2: The new prompt appeared below the complete multiline command. > > > > bash-4.3: The new prompt appears right under the previous prompt, > > overwriting parts of the aborted command line and leaving garbage after > the > > new prompt. > > Cannot reproduce: > > chris@lakes:~$ while : > > do > > : > > : > > :^C > chris@lakes:~$ echo $BASH_VERSION > 4.3.0(1)-release > > Does this happen when you execute bash without sourcing the profile/rc? >
Re: multiline ^C regression
Egmont Koblinger writes: > Sorry, I wasn't clear enough. > > By "multiline" I mean a simple command that is so long (e.g. takes so many > parameters) that it cannot fit into a single line. (You reach the right > margin of your terminal and keep on typing.) I can reproduce that, and the subsequent garbage. Thanks for clarifying. pgpWwd50M2dFf.pgp Description: PGP signature
read portability
As I'm sure everybody knows, Bash is the only shell that supports indexed arrays but maps the option for reading fields to -a rather than -A. I realize that "read -A" was an unfortunate, confusing choice in contrast to "typeset -a", but this is a feature that I use in almost every script, and would "just work" everywhere if it wasn't for the backwards option. Could we just add it as an alternate? A real proper wrapper around read to fix this in a script requires a full-on option parser to handle both "-a x" and "-ax" forms. Ideally it also has to fix the collision with the coprocess feature in at least 3 other implementations and translate between "var?prompt" and "-p prompt". Also "-i default" <-> "var=default; read -v var" (ksh93). I have such a function of course, but don't care to make every script depend on it. The -a/-A problem is definitely the most common and annoying of these though and the -A would be very useful even if left undocumented or marked as deprecated. -- Dan Douglas
Re: read portability
On Thu, Mar 27, 2014 at 3:16 AM, Dan Douglas wrote: > I have such a function of course, but don't care to make every script depend > on it. Oh, and of course I'll still be using the wrapper. This is a feature for my great grandchildren to use once Apple is out of business and the last Macs (that will still be shipping Bash 3 in 100 years) are out of commission, and the rest of the world has migrated to Bash 4.4. Better late than never though. -- Dan Douglas
Re: ls doesn't work in if statements in bash 4.3
On Wed, Mar 26, 2014 at 09:02:02PM -0700, billyco...@gmail.com wrote:
> The original intention was to play a randomly sorted list of songs (except
> ABBA):
See http://mywiki.wooledge.org/BashFAQ/026
I would use an approach like this:
files=()
while IFS= read -r -d '' file; do
files+=("$file")
done < <(find . -iname '*.mp3' ! -iname '*abba*' -print0)
This would populate an array with all of the non-abba filenames.
Then you can use the techniques from FAQ 26 to select a random array
element, as many times as needed.
> for f in `ls *.mp3 | grep -v abba | sort -R`
This is wrong. MP3 filenames ALMOST ALWAYS have spaces and other weird
rubbish in them. This code will fail horribly on filenames with spaces
in them.
>mplayer $f
So will this. This will fail horribly on filenames with spaces in them
because you forgot to quote "$f".
> for f in `find . -name "*.mp3" | grep -v abba | sort -R`
This is also wrong, for the reasons already given.
See http://mywiki.wooledge.org/BashPitfalls (it's the very first one, for
a reason).
On Wed, Mar 26, 2014 at 09:15:38PM -0700, billyco...@gmail.com wrote:
> for f in `ls dog*` doesn't work but
>
> for f in `find dog*` does work.
They are BOTH wrong.
If you are not recursing into subdirectories, just use for f in dog*
If you are recursing, then use find, but feed it to a while/read loop
with a process substitution. DO NOT use a command substitution that
spits out filenames.
for f in `find ...` # WRONG
while IFS= read -r file; do ...; done < <(find ...) # ACCEPTABLE
while IFS= read -r -d '' file; do ...; done < <(find ... -print0) # BULLETPROOF
(The ACCEPTABLE one fails on filenames that contain newlines. These
are rare but possible. The BULLETPROOF one works on any filename.)
And for your immediate problem, get rid of the "always colorize ls output"
setting and replace it with the "colorize ls output if stdout is a terminal"
setting. (Or get rid of the colorization entirely.) I don't know how
you've got it configured, but I do know that "ls --color=always" is wrong
but "ls --color=auto" is OK.
easier construction of arrays
On Thu 27 Mar 2014 08:01:45 Greg Wooledge wrote:
> files=()
> while IFS= read -r -d '' file; do
> files+=("$file")
> done < <(find . -iname '*.mp3' ! -iname '*abba*' -print0)
i've seen this construct duplicated so many times :(. i wish we had a native
option for it. maybe something like:
read -A files -r -d '' < <(find . -iname '*.mp3' -print0)
perhaps there is another shell out there that implements something that can
replace that loop that bash can crib ?
-mike
signature.asc
Description: This is a digitally signed message part.
Re: ls doesn't work in if statements in bash 4.3
On Wednesday, March 26, 2014 8:30:12 PM UTC-4, billy...@gmail.com wrote: > I tested on bash 4.3 and 3.0 > > > > testing]$ bash --version > > bash --version > > GNU bash, version 4.3.0(1)-release (x86_64-unknown-linux-gnu) > > > > In a directory I have: > > > > testing]$ ls -l > > total 16 > > -rw-r--r-- 1 hpierce hpierce 77 Mar 26 20:09 dog1 > > -rw-r--r-- 1 hpierce hpierce 77 Mar 26 20:09 dog2 > > -rw-r--r-- 1 hpierce hpierce 77 Mar 26 20:09 dog3 > > -rw-r--r-- 1 hpierce hpierce 0 Mar 26 20:07 dog4 > > -rwxr-xr-x 1 hpierce hpierce 80 Mar 26 20:02 test > > > > dog1, dog2, and dog3 have content. dog4 is empty. > > > > test is a simple script: > > > > testing]$ cat test > > #!/bin/bash > > FILE=$1 > > echo $FILE > > if [ ! -e $FILE ] > > then > > echo "Usage: $0 " > > exit 1 > > else > > echo $FILE exists > > fi > > > > Here's a regular run: > > > > testing]$ for f in *; do ./test $f; done > > dog1 > > dog1 exists > > dog2 > > dog2 exists > > dog3 > > dog3 exists > > dog4 > > dog4 exists > > test > > test exists > > > > Now I add a ls: > > > > testing]$ for f in `ls dog*`; do ./test $f; done > > dog1 > > Usage: ./test > > dog2 > > Usage: ./test > > dog3 > > Usage: ./test > > dog4 > > Usage: ./test > > > > So I moved it to an earlier version of bash > > > > testing]$ bash --version > > bash --version > > GNU bash, version 3.00.15(1)-release (x86_64-redhat-linux-gnu) > > > > testing]$ for f in `ls dog*`; do ./test $f; done > > dog1 > > dog1 exists > > dog2 > > dog2 exists > > dog3 > > dog3 exists > > dog4 > > dog4 exists These restrictions that you talk about are important, but you don't seem to hear me when I say "My filenames never have spaces". My directories never have spaces. I am meticulous about my filesystems. On one hand I realize you think you're being helpful to someone who has just started bash programming, but since I've been at this for > 12 years it has gotten a little condescending. I solved the issue myself about 10 minutes later. I thought it was interesting that with the problematic dir_colors file I was unable to use 'ls' but 'find' worked. I work as a system administrator so I understand that people are at different levels in terms of technical knowledge. It's all about reading comprehension. If you had read "My filenames never have spaces" part and actually paid attention you would see that the problem had nothing to do with spaces. But no. Everyone wants to show how smart they are that spaces can mess things up. Wow! Thanks! My guess is that you'll breeze right past this post and continue to give me helpful hints. Thanks guys! --Snarky System Administrator (Is there any other kind?)
Re: ls doesn't work in if statements in bash 4.3
> These restrictions that you talk about are important, but you don't seem to > hear me when I say "My filenames never have spaces". My directories never > have spaces. I am meticulous about my filesystems. On one hand I realize > you think you're being helpful to someone who has just started bash > programming, but since I've been at this for > 12 years it has gotten a > little condescending. I solved the issue myself about 10 minutes later. I > thought it was interesting that with the problematic dir_colors file I was > unable to use 'ls' but 'find' worked. I work as a system administrator so I > understand that people are at different levels in terms of technical > knowledge. It's all about reading comprehension. If you had read "My > filenames never have spaces" part and actually paid attention you would see > that the problem had nothing to do with spaces. But no. Everyone wants to > show how smart they are that spaces can mess things up. Wow! Thanks! My > guess is that you'll breeze right past this post and continue to give me > helpful hints. Thanks guys! > > --Snarky System Administrator (Is there any other kind?) Who are you replying to? Since you do not address a specific person, or at least keep part of the email you're replying to. And I read the whole thread, and the only thing you mention is: > I have a script which goes out and converts all my filenames (/home/user/) > with > spaces into filenames with underscores. I also convert them to lower case. Well, that's cool. But spaces are not the only characters that break that for loop. But, OK, lets pretend your environment is perfect, that your filenames don't have spaces, tabs, newlines, asterisks, question marks, and so on. Even with all this in mind, don't rely on word splitting. There's a simpler, easier to read way of doing it, which is: let the shell expand the globs! And this whole thread is just ironic. You're defending that your approach is right, but using that same flawed approach caused you this issue in the first place! (the dir_colors issue most likely caused terminal sequences to be captured by `...`, messing with your filenames). Anyways. Documented behavior, so, no bash bug. Try to use help-bash next time though, for scripting issues (that aren't bash bugs). Also, I recommend you to use 'set -x' more often, it's awesome to catch these types of bugs caused by non-graphic stuff. -- Eduardo Alan Bustamante López
Re: easier construction of arrays
On Thu, Mar 27, 2014 at 5:53 PM, Mike Frysinger wrote:
> On Thu 27 Mar 2014 08:01:45 Greg Wooledge wrote:
> > files=()
> > while IFS= read -r -d '' file; do
> > files+=("$file")
> > done < <(find . -iname '*.mp3' ! -iname '*abba*' -print0)
>
> i've seen this construct duplicated so many times :(. i wish we had a
> native
> option for it. maybe something like:
> read -A files -r -d '' < <(find . -iname '*.mp3' -print0)
>
> perhaps there is another shell out there that implements something that can
> replace that loop that bash can crib ?
> -mike
An option to change the delimiter for readarray/mapfile?
#!path
Hi, I was reading the bash manual at: "If the program is a file beginning with #!, the remainder of the first line specifies an interpreter for the pro‐ gram. The shell executes the specified interpreter on operating systems that do not handle this executable format themselves.| I need to specify a variable path after #! but seems to me that bash can't do this. For example I need to specify the $HOME or ~ path as in: #!~/bin/python or #!$HOME/bin/python instead of #!/home/myname/bin/python is there away to do this thing? thanks for any help. j -- View this message in context: http://gnu-bash.2382.n7.nabble.com/path-tp13212.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: #!path
On Thu, Mar 27, 2014 at 08:19:39AM -0700, esoj wrote: > I need to specify a variable path after #! but seems to me that bash can't > do this. > For example I need to specify the $HOME or ~ path as in: > > > #!~/bin/python > or > #!$HOME/bin/python This belongs on help-bash, not bug-bash. That said, you can't do this directly with the shebang, because the kernel doesn't care about ~ or $HOME. It just knows file paths. (That bit in the manual about "the shell does it if the OS doesn't" is just a fallback for some really strange systems. On almost any system you are likely to use, the kernel handles the shebang, not bash. In fact, bash would only be able to handle it if you were running the program FROM bash in the first place.) The typical workaround is to write some clever boilerplate code at the top of the script which is interpreted a comment (or a no-op) in one language, and a valid instruction (to reinvoke the program with a different interpreter) in another language. In this case, you want the shebang to be #!/bin/sh, and you want boilerplate code that invokes the script under ~/bin/python when the script is run by /bin/sh, but which does nothing when it's invoked by python. I would imagine some Python FAQ has this somewhere... let's see what Google turns up. http://softwareswirl.blogspot.com/2011/06/starting-python-script-intelligently.html http://stackoverflow.com/questions/19304295/make-usr-bin-env-python-u-shebang-portable There, that's not bad. The first answer in the second URL is nice and short.
Re: ls doesn't work in if statements in bash 4.3
On Wednesday, March 26, 2014 8:30:12 PM UTC-4, billy...@gmail.com wrote: > I tested on bash 4.3 and 3.0 > > > > testing]$ bash --version > > bash --version > > GNU bash, version 4.3.0(1)-release (x86_64-unknown-linux-gnu) > > > > In a directory I have: > > > > testing]$ ls -l > > total 16 > > -rw-r--r-- 1 hpierce hpierce 77 Mar 26 20:09 dog1 > > -rw-r--r-- 1 hpierce hpierce 77 Mar 26 20:09 dog2 > > -rw-r--r-- 1 hpierce hpierce 77 Mar 26 20:09 dog3 > > -rw-r--r-- 1 hpierce hpierce 0 Mar 26 20:07 dog4 > > -rwxr-xr-x 1 hpierce hpierce 80 Mar 26 20:02 test > > > > dog1, dog2, and dog3 have content. dog4 is empty. > > > > test is a simple script: > > > > testing]$ cat test > > #!/bin/bash > > FILE=$1 > > echo $FILE > > if [ ! -e $FILE ] > > then > > echo "Usage: $0 " > > exit 1 > > else > > echo $FILE exists > > fi > > > > Here's a regular run: > > > > testing]$ for f in *; do ./test $f; done > > dog1 > > dog1 exists > > dog2 > > dog2 exists > > dog3 > > dog3 exists > > dog4 > > dog4 exists > > test > > test exists > > > > Now I add a ls: > > > > testing]$ for f in `ls dog*`; do ./test $f; done > > dog1 > > Usage: ./test > > dog2 > > Usage: ./test > > dog3 > > Usage: ./test > > dog4 > > Usage: ./test > > > > So I moved it to an earlier version of bash > > > > testing]$ bash --version > > bash --version > > GNU bash, version 3.00.15(1)-release (x86_64-redhat-linux-gnu) > > > > testing]$ for f in `ls dog*`; do ./test $f; done > > dog1 > > dog1 exists > > dog2 > > dog2 exists > > dog3 > > dog3 exists > > dog4 > > dog4 exists Your response is "I recommend you to use 'set -x'"? Nice. Unfortunately it also means you're a troll, so further discussion with you is pointless.
Re: ls doesn't work in if statements in bash 4.3
> Your response is "I recommend you to use 'set -x'"? Nice. Unfortunately it > also means you're a troll, so further discussion with you is pointless. > Well, care to explain why I'm labeled as a troll? I ran the following: | bash-4.3$ mkdir a b c | bash-4.3$ touch 1 2 3 | bash-4.3$ (set -x; echo '===1'; for file in `ls --color=never`; do [ -e "$file" ] && echo "$file"; done; echo '===2'; for file in `ls --color=always`; do [ -e "$file" ] && echo "$file"; done;) | + echo ===1 | ===1 | ++ ls --color=never | + for file in '`ls --color=never`' | + '[' -e 1 ']' | + echo 1 | 1 | + for file in '`ls --color=never`' | + '[' -e 2 ']' | + echo 2 | 2 | + for file in '`ls --color=never`' | + '[' -e 3 ']' | + echo 3 | 3 | + for file in '`ls --color=never`' | + '[' -e a ']' | + echo a | a | + for file in '`ls --color=never`' | + '[' -e b ']' | + echo b | b | + for file in '`ls --color=never`' | + '[' -e c ']' | + echo c | c | + echo ===2 | ===2 | ++ ls --color=always | + for file in '`ls --color=always`' | + '[' -e 1 ']' | + echo 1 | 1 | + for file in '`ls --color=always`' | + '[' -e 2 ']' | + echo 2 | 2 | + for file in '`ls --color=always`' | + '[' -e 3 ']' | + echo 3 | 3 | + for file in '`ls --color=always`' | + '[' -e 'a' ']' | + for file in '`ls --color=always`' | + '[' -e 'b' ']' | + for file in '`ls --color=always`' | + '[' -e 'c' ']' Due to limitations on what can be sent by email, you won't be able to notice that the last three entries are shown in color. But running this on a terminal will make that evident quickly. And this would've hinted you immediately what the issue was. (but hey, I'm a troll ;) ) --- Also, on a slightly different issue, please... really, please, use Google Groups properly. It's VERY annoying to have to skip through pages of text just to see your 1 line reply. Also, it appears as if you're replying to yourself. This makes it hard to know who you're talking to. Follow the suggestions here to make the experience less painful to us who have to read you: https://wiki.python.org/moin/GoogleGroupsPython -- Eduardo Alan Bustamante López
Re: multiline ^C regression
On 3/27/14 3:40 AM, Egmont Koblinger wrote:
> Hi,
>
> Type a multiline command, and press ^C.
>
> bash-4.2: The new prompt appeared below the complete multiline command.
>
> bash-4.3: The new prompt appears right under the previous prompt,
> overwriting parts of the aborted command line and leaving garbage after the
> new prompt.
Thanks for the report. This is a consequence of bash and readline's
reworked signal handling, which moves processing out of signal handlers.
I've attached a patch that will fix this problem.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.3-patched/lib/readline/display.c 2013-12-27 13:10:56.0 -0500
--- lib/readline/display.c 2014-03-27 11:52:45.0 -0400
***
*** 2678,2682
if (_rl_echoing_p)
{
! _rl_move_vert (_rl_vis_botlin);
_rl_vis_botlin = 0;
fflush (rl_outstream);
--- 2678,2683
if (_rl_echoing_p)
{
! if (_rl_vis_botlin > 0) /* minor optimization plus bug fix */
! _rl_move_vert (_rl_vis_botlin);
_rl_vis_botlin = 0;
fflush (rl_outstream);
Re: multiline ^C regression
Awesome, thanks for the super fast fix :) e. On Thu, Mar 27, 2014 at 7:26 PM, Chet Ramey wrote: > On 3/27/14 3:40 AM, Egmont Koblinger wrote: > > Hi, > > > > Type a multiline command, and press ^C. > > > > bash-4.2: The new prompt appeared below the complete multiline command. > > > > bash-4.3: The new prompt appears right under the previous prompt, > > overwriting parts of the aborted command line and leaving garbage after > the > > new prompt. > > Thanks for the report. This is a consequence of bash and readline's > reworked signal handling, which moves processing out of signal handlers. > > I've attached a patch that will fix this problem. > > Chet > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ >
Re: ls doesn't work in if statements in bash 4.3
On Thursday, March 27, 2014 2:15:22 PM UTC-4, Eduardo A. Bustamante López wrote: > > Your response is "I recommend you to use 'set -x'"? Nice. Unfortunately > > it also means you're a troll, so further discussion with you is pointless. > > > > > > > Well, care to explain why I'm labeled as a troll? > > > > > > I ran the following: > > > > | bash-4.3$ mkdir a b c > > | bash-4.3$ touch 1 2 3 > > | bash-4.3$ (set -x; echo '===1'; for file in `ls --color=never`; do [ -e > "$file" ] && echo "$file"; done; echo '===2'; for file in `ls > --color=always`; do [ -e "$file" ] && echo "$file"; done;) > > | + echo ===1 > > | ===1 > > | ++ ls --color=never > > | + for file in '`ls --color=never`' > > | + '[' -e 1 ']' > > | + echo 1 > > | 1 > > | + for file in '`ls --color=never`' > > | + '[' -e 2 ']' > > | + echo 2 > > | 2 > > | + for file in '`ls --color=never`' > > | + '[' -e 3 ']' > > | + echo 3 > > | 3 > > | + for file in '`ls --color=never`' > > | + '[' -e a ']' > > | + echo a > > | a > > | + for file in '`ls --color=never`' > > | + '[' -e b ']' > > | + echo b > > | b > > | + for file in '`ls --color=never`' > > | + '[' -e c ']' > > | + echo c > > | c > > | + echo ===2 > > | ===2 > > | ++ ls --color=always > > | + for file in '`ls --color=always`' > > | + '[' -e 1 ']' > > | + echo 1 > > | 1 > > | + for file in '`ls --color=always`' > > | + '[' -e 2 ']' > > | + echo 2 > > | 2 > > | + for file in '`ls --color=always`' > > | + '[' -e 3 ']' > > | + echo 3 > > | 3 > > | + for file in '`ls --color=always`' > > | + '[' -e 'a' ']' > > | + for file in '`ls --color=always`' > > | + '[' -e 'b' ']' > > | + for file in '`ls --color=always`' > > | + '[' -e 'c' ']' > > > > > > Due to limitations on what can be sent by email, you won't be able to > > notice that the last three entries are shown in color. But running > > this on a terminal will make that evident quickly. And this would've > > hinted you immediately what the issue was. > > > > (but hey, I'm a troll ;) ) > > > > > > > > > > --- > > Also, on a slightly different issue, please... really, please, use > > Google Groups properly. It's VERY annoying to have to skip through > > pages of text just to see your 1 line reply. Also, it appears as if > > you're replying to yourself. This makes it hard to know who you're > > talking to. > > > > Follow the suggestions here to make the experience less painful to us > > who have to read you: https://wiki.python.org/moin/GoogleGroupsPython > > > > -- > > Eduardo Alan Bustamante López That actually did fix the issue. Instead of: for f in `ls *.mp3` I used for f in `/bin/ls *.mp3` but your example for file in '`ls --color=never`' is good. So there are some issues with ls and color. This I think is interesting. Not sure whether it qualifies as a bug. I should not have given up on you. I was also wrong in my usage of the reply function. There were communication issues. Your behaviour was similar to a troll. Why would you tell me "set -x" when I mentioned that I have done shell programming for > 12 years? Why would you ignore the fact that I told you I am meticulous with my environment? What a troll does is deliberately misread information so that they can tell you things that you already know. A troll never admits that they are wrong, and they tell you that you are doing things wrong. You know that there are a million ways to program. It's part of the beauty. I maintain all the scripts at work, but I never tell people how to program. If it works, then that's good. I love keeping an environment with perfect directories and filenames. I don't do it so I can do sloppy programming. I love shell programming because it's quick and dirty. I also program in perl, awk, expect, python, and ruby. It's a matter of respect. I tend to err on the side of talking above people's level rather than talk down to them. Just try to think how you would respond if someone told you to use 'set -x'. I do appreciate your help. As long as I've been at it I never bothered with colors. It's just so fascinating that it could have this effect.
4.3 crash entering q! and exiting the shell
seen when entering q!, then leaving the shell with ^D $ gdb bash (gdb) run Starting program: /bin/bash doko@gb:~$ q! q!: Befehl nicht gefunden. doko@gb:~$ malloc: .././parse.y:2314: assertion botched realloc: start and end chunk sizes differ last command: q! Aborting... Program received signal SIGABRT, Aborted. 0x7761df79 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x7761df79 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x77621388 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x0044054f in programming_error () #3 0x004b4bc0 in ?? () #4 0x00472bb6 in sh_xrealloc () #5 0x00423879 in ?? () #6 0x00426612 in ?? () #7 0x00429c39 in yyparse () #8 0x00420ebb in parse_command () #9 0x00420f8c in read_command () #10 0x00421189 in reader_loop () #11 0x0041f729 in main () (gdb) quit
Re: 4.3 crash entering q! and exiting the shell
On 3/27/14 2:36 PM, Matthias Klose wrote:
> seen when entering q!, then leaving the shell with ^D
Thanks. It's actually running any other command after the failed expansion
causes the input line to be resized. Here's a patch.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.3-patched/parse.y 2014-02-11 09:42:10.0 -0500
--- parse.y 2014-03-27 16:33:29.0 -0400
***
*** 2425,2429
if (shell_input_line_terminator != EOF)
{
! if (shell_input_line_size < SIZE_MAX && shell_input_line_len > shell_input_line_size - 3)
shell_input_line = (char *)xrealloc (shell_input_line,
1 + (shell_input_line_size += 2));
--- 2425,2429
if (shell_input_line_terminator != EOF)
{
! if (shell_input_line_size < SIZE_MAX-3 && (shell_input_line_len+3 > shell_input_line_size))
shell_input_line = (char *)xrealloc (shell_input_line,
1 + (shell_input_line_size += 2));
Re: 4.3 crash entering q! and exiting the shell
On Thu, Mar 27, 2014 at 07:36:56PM +0100, Matthias Klose wrote:
> seen when entering q!, then leaving the shell with ^D
>
> $ gdb bash
> (gdb) run
> Starting program: /bin/bash
> doko@gb:~$ q!
> q!: Befehl nicht gefunden.
> doko@gb:~$
> malloc: .././parse.y:2314: assertion botched
> realloc: start and end chunk sizes differ
> last command: q!
> Aborting...
> Program received signal SIGABRT, Aborted.
> 0x7761df79 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0 0x7761df79 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1 0x77621388 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2 0x0044054f in programming_error ()
> #3 0x004b4bc0 in ?? ()
> #4 0x00472bb6 in sh_xrealloc ()
> #5 0x00423879 in ?? ()
> #6 0x00426612 in ?? ()
> #7 0x00429c39 in yyparse ()
> #8 0x00420ebb in parse_command ()
> #9 0x00420f8c in read_command ()
> #10 0x00421189 in reader_loop ()
> #11 0x0041f729 in main ()
> (gdb) quit
>
I noticed that this just happens for a single character, followed by
the '!', when history expansion is enabled:
| dualbus@debian ~ % bash
| bash-4.3$ a!
| bash: a!: command not found
| bash-4.3$
| malloc: ./parse.y:2314: assertion botched
| realloc: start and end chunk sizes differ
| last command: a!
| Aborting...zsh: abort bash
| dualbus@debian ~ % bash
| bash-4.3$ aa!
| bash: aa!: command not found
| bash-4.3$ exit
| dualbus@debian ~ % bash
| bash-4.3$ set +H
| bash-4.3$ a!
| bash: a!: command not found
| bash-4.3$ exit
This is the change that introduced the error:
| % git show 36eb585cfa52fbb6cd0c324c628593ea856a50a5 -- parse.y
And I've attached a patch (well, it's basically just a revert of part of that
change), that "fixes" the issue. I blindly reverted, so I don't know
what error was that specific patch supposed to fix in the first
place. Take my patch just as a pointer of where the issue is.
--
Eduardo Alan Bustamante López
diff --git a/parse.y b/parse.y
index 83d5b9f..5e3ccde 100644
--- a/parse.y
+++ b/parse.y
@@ -2288,30 +2288,7 @@ shell_getc (remove_quoted_newline)
continue;
}
- /* Theoretical overflow */
- /* If we can't put 256 bytes more into the buffer, allocate
- everything we can and fill it as full as we can. */
- /* XXX - we ignore rest of line using `truncating' flag */
- if (shell_input_line_size > (SIZE_MAX - 256))
- {
- size_t n;
-
- n = SIZE_MAX - i; /* how much more can we put into the buffer? */
- if (n <= 2) /* we have to save 1 for the newline added below */
- {
- if (truncating == 0)
- internal_warning("shell_getc: shell_input_line_size (%zu) exceeds SIZE_MAX (%llu): line truncated", shell_input_line_size, SIZE_MAX);
- shell_input_line[i] = '\0';
- truncating = 1;
- }
- if (shell_input_line_size < SIZE_MAX)
- {
- shell_input_line_size = SIZE_MAX;
- shell_input_line = xrealloc (shell_input_line, shell_input_line_size);
- }
- }
- else
- RESIZE_MALLOCED_BUFFER (shell_input_line, i, 2, shell_input_line_size, 256);
+ RESIZE_MALLOCED_BUFFER (shell_input_line, i, 2, shell_input_line_size, 256);
if (c == EOF)
{
@@ -2424,7 +2401,7 @@ shell_getc (remove_quoted_newline)
not already end in an EOF character. */
if (shell_input_line_terminator != EOF)
{
- if (shell_input_line_size < SIZE_MAX && shell_input_line_len > shell_input_line_size - 3)
+ if (shell_input_line_len + 3 > shell_input_line_size)
shell_input_line = (char *)xrealloc (shell_input_line,
1 + (shell_input_line_size += 2));
Re: easier construction of arrays
I don't believe any shell can currently read nul-delimited input into
an array without looping. It's been suggested to add a delimiter to
mapfile. It looks like mapfile uses zgetline() to wrap around calls to
zread() and doesn't support any delimiter. read(1) on the other hand
uses one of the zread functions directly depending upon what it's
trying to do. I would guess there are some performance differences.
On Thu, Mar 27, 2014 at 12:15 PM, Pierre Gaston wrote:
> On Thu, Mar 27, 2014 at 5:53 PM, Mike Frysinger wrote:
>
>> On Thu 27 Mar 2014 08:01:45 Greg Wooledge wrote:
>> > files=()
>> > while IFS= read -r -d '' file; do
>> > files+=("$file")
>> > done < <(find . -iname '*.mp3' ! -iname '*abba*' -print0)
>>
>> i've seen this construct duplicated so many times :(. i wish we had a
>> native
>> option for it. maybe something like:
>> read -A files -r -d '' < <(find . -iname '*.mp3' -print0)
>>
>> perhaps there is another shell out there that implements something that can
>> replace that loop that bash can crib ?
>> -mike
>
>
> An option to change the delimiter for readarray/mapfile?
Re: easier construction of arrays
On Thu 27 Mar 2014 19:15:13 Pierre Gaston wrote:
> On Thu, Mar 27, 2014 at 5:53 PM, Mike Frysinger wrote:
> > On Thu 27 Mar 2014 08:01:45 Greg Wooledge wrote:
> > > files=()
> > > while IFS= read -r -d '' file; do
> > >
> > > files+=("$file")
> > >
> > > done < <(find . -iname '*.mp3' ! -iname '*abba*' -print0)
> >
> > i've seen this construct duplicated so many times :(. i wish we had a
> > native
> >
> > option for it. maybe something like:
> > read -A files -r -d '' < <(find . -iname '*.mp3' -print0)
> >
> > perhaps there is another shell out there that implements something that
> > can replace that loop that bash can crib ?
>
> An option to change the delimiter for readarray/mapfile?
thanks, i wasn't aware of that func. that seems like the easiest solution.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: easier construction of arrays
On Thu, Mar 27, 2014 at 5:05 PM, Mike Frysinger wrote: > thanks, i wasn't aware of that func. that seems like the easiest solution. mapfile it awesome, but for getting find(1) results into an array you should continue to use a read -rd '' loop. read -d is somewhat portable, and mapfile does not support a safe delimiter.
Re: Bug#740971: completion fails on file names with special characters
On 3/27/14, 4:57 PM, Uwe Storbeck wrote:
> $ ls a(
>
> results in a wrong completion:
>
> $ ls a(a
This is something different. I addressed it in my first reply in this
thread:
"For instance, I believe that the problem with these unquoted special
characters is that they break words for readline, and readline passes
an empty argument to the completion function as the word to be completed."
The `(' is a character that breaks words for readline. Readline passes
an empty string to the bash completion function, which completes
it to the longest common prefix of the possible completions.
There is a difference between bash-4.2 and bash-4.3 in how it treats
this word. bash-4.3 does not interpret it the `(' as a command
delimiter (as it did in bash-4.2) because it's preceded by a character
that is not a command delimiter. bash-4.2 incorrectly treated that
construct as valid and attempted to perform command completion; since
it's a syntax error, bash-4.3 doesn't. There aren't any valid completions
for the empty string, so bash doesn't do anything and readline attempts
its default filename completion. The longest common prefix of the
possible filename completions is "a", which readline inserts into the
line buffer.
Since that line, as you entered it above, is a syntax error, it's not
clear what bash should do with it (probably nothing). What do you
expect to happen?
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bug#740971: completion fails on file names with special characters
On Mar 20, Chet Ramey wrote:
> I've updated the patch, and attached it. This seems to fix all of the
> reported problems from Debian's version of bash-completion.
It looks like this patch is included in Debian bash version
4.3-4. Most of my examples for bash completion which started to
fail with bash 4.3 are working again now. But one example still
fails, though I don't know if this is a problem of bash or
bash-completion:
$ mkdir /tmp/test && cd /tmp/test && touch aa 'a('
$ ls a
a( aa
So far it's ok. But:
$ ls a(
results in a wrong completion:
$ ls a(a
Uwe
Re: Bug#740971: completion fails on file names with special characters
On Mar 27, Chet Ramey wrote:
> Since that line, as you entered it above, is a syntax error, it's not
> clear what bash should do with it (probably nothing). What do you
> expect to happen?
The same as if you would try to complete any non-existing file
name, nothing? The completion should not append an "a" to the
typed in "a(". Instead the cursor should stay in the same
position (after the parenthesis) and bash should beep.
When you try to complete "ls ab" with in the same example
with the two files "aa" and "a(" in a directory bash-completion
handles it correctly. It only fails because of the parenthesis
(and maybe also with other special characters).
Uwe
Re: Bug#740971: completion fails on file names with special characters
On 3/27/14, 7:11 PM, Uwe Storbeck wrote:
> On Mar 27, Chet Ramey wrote:
>> Since that line, as you entered it above, is a syntax error, it's not
>> clear what bash should do with it (probably nothing). What do you
>> expect to happen?
>
> The same as if you would try to complete any non-existing file
> name, nothing? The completion should not append an "a" to the
> typed in "a(". Instead the cursor should stay in the same
> position (after the parenthesis) and bash should beep.
Yes, if bash can detect a syntax error, that's probably the best
thing.
> When you try to complete "ls ab" with in the same example
> with the two files "aa" and "a(" in a directory bash-completion
> handles it correctly. It only fails because of the parenthesis
> (and maybe also with other special characters).
There is virtually nothing common between the two cases other than
the fact that they are two-character strings beginning with `a'.
This has nothing to do with bash-completion (maybe I should remove
the debian bug address from the recipients).
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
/dev/fd/62: No such file or directory
When a system is not fully up or limping, various services like udevd may not be mounted yet -- proc may not be mounted yet. But it appears there are features in bash that try to use external paths to access process descriptors in itself (rather than just using them directly). If there is a need to pick up those fd's, I think it would be prudent if bash, **internally**, did not rely on os-mechanisms that may not be there ... Note -- I'm not saying bash should attempt to do something about a user's use of /dev/stdin or whatever in a script. but specifically I've seen above error message /dev/fd/62 (not sure if it was just 62, maybe 63 as well?) a fair amount after, I think, 4.3. I certainly wouldn't be against a builtin that would return the same thing as /dev/fd/62 -- just one that doesn't try to walk an external path to perform internal functions (have looked several times at scripts that have shown such messages, and have yet to see any mention of /dev/fd/xx in the script, so I'm /presuming/ (sigh) that it is something internal to bash?
Re: /dev/fd/62: No such file or directory
On 3/27/14, 8:42 PM, Linda Walsh wrote: > I certainly wouldn't be against a builtin that would return > the same thing as /dev/fd/62 -- just one that doesn't try to > walk an external path to perform internal functions (have looked > several times at scripts that have shown such messages, and > have yet to see any mention of /dev/fd/xx in the script, so I'm > /presuming/ (sigh) that it is something internal to bash? Process substitution, whose entire reason for existence is to turn a (pipe) file descriptor into a filename. If you want to use process substitution in a context where /dev/fd might not be available, make sure you don't tell bash to use it at build time or use another scripting technique. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: ls doesn't work in if statements in bash 4.3
billyco...@gmail.com writes: > > huge wall of text First of all, please follow basic etiquette and trim your quotes to what is relevant. I can't even fit your e-mail on my entire screen. > On one hand I realize you think you're being helpful to someone who > has just started bash programming, but since I've been at this for > 12 years it has gotten a little condescending. I solved the issue > myself about 10 minutes later. I thought it was interesting that with > the problematic dir_colors file I was unable to use 'ls' but 'find' > worked. I work as a system administrator so I understand that people > are at different levels in terms of technical knowledge. It's all > about reading comprehension. If you had read "My filenames never have > spaces" part and actually paid attention you would see that the > problem had nothing to do with spaces. But no. Everyone wants to > show how smart they are that spaces can mess things up. Wow! Thanks! > My guess is that you'll breeze right past this post and continue to > give me helpful hints. Thanks guys! There is only one thing that is worse than a person that doesn't take advice and continues to ask regardless: the one that seeks advice, attacks those that try to help, and then in a fit of embarassment provides a perilously long, rambling e-mail to claim that they "knew it all along". Show some respect to the people on this list and don't post here if you're going to act in such a manner. It's simply disrespectful and rude. pgp7hJhfWMZDO.pgp Description: PGP signature
Re: /dev/fd/62: No such file or directory
Chet Ramey wrote: On 3/27/14, 8:42 PM, Linda Walsh wrote: I certainly wouldn't be against a builtin that would return the same thing as /dev/fd/62 -- just one that doesn't try to walk an external path to perform internal functions (have looked several times at scripts that have shown such messages, and have yet to see any mention of /dev/fd/xx in the script, so I'm /presuming/ (sigh) that it is something internal to bash? Process substitution, whose entire reason for existence is to turn a (pipe) file descriptor into a filename. If you want to use process substitution in a context where /dev/fd might not be available, make sure you don't tell bash to use it at build time or use another scripting technique. So whether or not to use /def/fd is a build time option? It's a minority of scripts but have noticed the message in some startup scripts. It's not just my scripts but vendor scripts as well. I'll have to find out why.. but it seems like it a "gotcha"...
Re: ls doesn't work in if statements in bash 4.3
On Fri 28 Mar 2014 10:23:17 Chris Down wrote: there's really nothing to add to Chris's wonderful post :) -mike signature.asc Description: This is a digitally signed message part.
