bug-bash@gnu.org
On Mon, Oct 19, 2009 at 6:08 AM, Chet Ramey wrote: > Sitaram Chamarty wrote: >> Hello, >> >> When the previous command was backgrounded (say "gvim >> filename.c &") and then you try some other command using >> Alt-., it expands to "&" and not "filename.c". >> >> Is this considered a bug? Or correct behaviour that just >> happens to be not useful in this specific case? > > M-. uses the last word from the previous line. If that happens to > be `&', that's what it uses. ok thanks; I suspected as much (that this was working as intended, and the situation I brought up was an edge case) but appreciate the confirmation.
Re: another problem with bash PS1 handling
On 19 Okt., 02:56, Chet Ramey wrote: > Second, there are a couple of problems with Posix and this construct. > You can make an argument that Posix doesn't apply, since it only > calls for parameter expansion on the value of PS1, and that does not > include command substitution. Even if it does apply, it's not clear > whether or not the expansion of ! to the history number should be > performed before or after the word expansions. Bash chooses to do it > before the expansion, since that's when it's scanning the string for > the other backslash-prefixed expansions it performs, and it looks like > ksh does it after the word expansions. Whether POSIX applies or not, from a logical standpoint history number and custom bash escape expansion should be last, after parameter expansion and command substitution because doing it first breaks command substitution (see my earlier post) or using variables in a prompt (a='!'; PS1='$a ' will result in a literal "!" rather than the history number), it is unintuitive and deviates from the behavior of other shells such as variants of ash and ksh.
Re: another problem with bash PS1 handling
> Whether POSIX applies or not, from a logical standpoint history number > and custom bash escape expansion should be last, after parameter > expansion and command substitution because doing it first breaks > command substitution (see my earlier post) or using variables in a > prompt (a='!'; PS1='$a ' will result in a literal "!" rather than the > history number), it is unintuitive and deviates from the behavior of > other shells such as variants of ash and ksh. I disagree. I don't see a compelling reason to change 20 years of behavior here. 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/
bug-bash@gnu.org
Sitaram Chamarty wrote: > Chet Ramey wrote: > > Sitaram Chamarty wrote: > >> When the previous command was backgrounded (say "gvim > >> filename.c &") and then you try some other command using > >> Alt-., it expands to "&" and not "filename.c". > >> > >> Is this considered a bug? Or correct behaviour that just > >> happens to be not useful in this specific case? > > > > M-. uses the last word from the previous line. If that happens to > > be `&', that's what it uses. > > ok thanks; I suspected as much (that this was working as intended, and > the situation I brought up was an edge case) but appreciate the > confirmation. Certainly yank-last-arg (M-.,M-_) is useful but don't forget about yank-nth-arg (M-C-y) which yanks the first argument. Most of the time that you are doing something like 'edit filename.c &' then you can use the still quite convenient M-C-y to paste in the filename as the first argument to the next command. Bob
Re: Prompt - cursor position - command history display problem
Timothy James Erlenmeyer wrote: > > 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-unknown-linux-gnu' -DCONF_VENDOR='unknown' > -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL > -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 > > uname output: Linux > cyclops4 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:47:07 EDT 2007 x86_64 > x86_64 x86_64 GNU/Linux > > Machine Type: x86_64-unknown-linux-gnu > > Bash > Version: 4.0 > > Patch Level: 28 > > Release Status: release > > Description: > > With > a color prompt, long directory names, and/or long command lines, scrolling > through the command history often causes the cursor to be in the wrong > position, the prompt to loose color and remnants of previous long commands > to remain on the line with short commands. > > Repeat-By: > > * This line is > placed in ~/.bashrc: > > PS1='[e[31;2m]w$[e[0m] ' Thanks for the report. My testing indicates that this has been fixed for the next version of bash. 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/
bug-bash@gnu.org
On Tue, Oct 20, 2009 at 2:22 AM, Bob Proulx wrote: > Certainly yank-last-arg (M-.,M-_) is useful but don't forget about > yank-nth-arg (M-C-y) which yanks the first argument. Most of the time > that you are doing something like 'edit filename.c &' then you can use > the still quite convenient M-C-y to paste in the filename as the first > argument to the next command. Cool thanks! Tantalisingly, it also says "nth" arg, but I can't figure out how to give it that "n" (when n != 1). However, it seems I can do this with M-. -- I just prefix an M-1 before the M-. (thought my terminal does get messed up; probably because I have a very complex bash prompt with colors and all...)
Small script that sometimes elicits a memory error
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-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 debian1.loaner.com 2.6.25-2-686 #1 SMP Fri Jun 27 03:23:20 UTC 2008 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 4.0 Patch Level: 33 Release Status: release Description: Sometime the following code causes: malloc: ../bash/subst.c:4198: assertion botched realloc: start and end chunk sizes differ Aborting...tmp/bug: line 283: 9468 Done 9469 Aborted (core dumped) Repeat-By: read -d '' v <
read: error setting terminal attributes: Interrupted system call
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-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 debian1.loaner.com 2.6.25-2-686 #1 SMP Fri Jun 27 03:23:20
UTC 2008 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33
Release Status: release
Description:
A proprietary script and data usually elcit
this error
: line 47: read: error setting terminal attributes:
Interrupted system call
Combine and ? [y/n]: n
malloc: ../../bash/builtins/../../bash/builtins/read.def:675: assertion
botched
free: underflow detected; mh_nbytes out of range
Aborting...: line 52: 32293
Doneawk -v lower_limit=.921 -v upper_limit=.999
'{if(lower_limit <= $6 && $6 <= upper_limit) {print}}'
$variable-containing-file-name
32294 | sort -g -k 6
32295 Aborted (core dumped)
Repeat-By:
Run the script and respond to
read -n 1 -p "Combine $variable1 and $variable2? [y/n]: " < /dev/tty
by pressing "y" or "n" a few times.
cp command will copy to subdirectory without appending /
The cp command will copy to a subdirectory without an appending / mkdir test test2 touch abc test touch bcd test2 cp -R test2 test ls test test2 abc Since the cp command can also rename I think the proper behavior here for 'cp -R test2 test' would be to error and print that 'Folder already exists'. Appending a / would imply the directory: cp -R test2 test/ This usage will remove the ambiguity of the command between the copy function and the rename function. -- When in trouble or in doubt run in circles, scream and shout. - Robert A. Heinlein My Linux Blog - http://linuxtidbits.wordpress.com
Re: cp command will copy to subdirectory without appending /
Todd Partridge wrote: > The cp command will copy to a subdirectory without an appending / You have reached bug-bash, not bug-coreutils. The 'cp' program is in the GNU Coreutils project and so bug reports for 'cp' should go to bug-coreut...@gnu.org and not to bug-bash. The bug-bash list is for bugs and discussion about bash. > mkdir test test2 > touch abc test > touch bcd test2 I think you have typed this in incorrectly. That produces: ./abc ./bcd ./test ./test2 > cp -R test2 test Because test is a directory test2 will be copied into that directory. With the above that produces: ./abc ./bcd ./test ./test/test2 ./test2 > ls test > test2 abc That result cannot be produced from the given commands. Please rephrase the question. > Since the cp command can also rename I think you misunderstand how cp works. A quick and casual summary here. If the target is not a directory then the source file (singular) is copied to the destination. If the target is a directory then cp copies the source files (one or more) into the destination directory. If the target has an appended '/' then the destination must be a directory. Here is the full standards document: http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html > I think the proper behavior here for 'cp -R test2 test' would be to > error and print that 'Folder already exists'. Of course that would break decades of scripts which expect the standard behavior. I don't understand why would you change this long standing useful behavior. Could you say a few words more about what your problem is with the current behavior? > Appending a / would imply the directory: > cp -R test2 test/ > This usage will remove the ambiguity of the command between the copy > function and the rename function. Please rephrase your question and send it to bug-coreut...@gnu.org. Thanks Bob
