Re: Command substitution (backtick) and tab completion
On Jan 1, 11:20 pm, Chet Ramey wrote: > On 12/31/10 11:01 PM, Sven Mascheck wrote: > > > On Fri, Dec 31, 2010 at 12:20:38PM -0800, chengiz wrote: > >> On Dec 31, 12:20 pm, Sven Mascheck wrote: > > >>> (see alsohttp://lists.gnu.org/archive/html/bug-bash/2008-01/msg00049.html) > >>> [...] > > >> I dont see how that's related - I dont doubt you that the fix to this > >> issue "broke" my example, but in that case there's premature > >> execution, in my case the ticks are closed. [...] > > > Here's how I understood it: > > The original problem was just the trigger. The decision was to completely > > disable command substitution while the completion system is active here. > > That's why I posted the bug report link: just see the reply from Chet. > > The idea is that it's not safe, in general, to run arbitrary command > substitutions more than once. They may have side effects. > > Chet So if I get this right, the only time this is a problem is when the command substitution runs more than once. When does this happen? Not in my "ls `pwd`/" example where the command runs once and replaces itself with its output. Does it only run more than once when the ticks are not complete? In that case I reiterate that I dont see how the fix is related to the reported bug.
Re: Command substitution (backtick) and tab completion
On Wed, Jan 05, 2011 at 08:21:18AM -0800, chengiz wrote: > So if I get this right, the only time this is a problem is when the > command substitution runs more than once. I'd actually characterize it differently: it's unsafe to run arbitrary commands during tab completion, because bash doesn't know what those commands might do. > When does this happen? Not > in my "ls `pwd`/" example where the command runs once and > replaces itself with its output. Does it only run more than once when > the ticks are not complete? You might realize you made a mistake, hit Ctrl-U, and start over. But the backticked command has already been executed. You might hit ESC # to comment out the command line because you suddenly realize that you need to do something else first. Then you come back to it (ESC k k ...), remove the # sign, finish typing the command, and run it. But the backticked command was already executed much earlier than you might have wished (two commands ago).
Re: Command substitution (backtick) and tab completion
On 01/05/2011 09:57 AM, Greg Wooledge wrote: > On Wed, Jan 05, 2011 at 08:21:18AM -0800, chengiz wrote: >> So if I get this right, the only time this is a problem is when the >> command substitution runs more than once. > > I'd actually characterize it differently: it's unsafe to run arbitrary > commands during tab completion, because bash doesn't know what those > commands might do. > >> When does this happen? Not >> in my "ls `pwd`/" example where the command runs once and >> replaces itself with its output. Does it only run more than once when >> the ticks are not complete? > > You might realize you made a mistake, hit Ctrl-U, and start over. But > the backticked command has already been executed. > > You might hit ESC # to comment out the command line because you suddenly > realize that you need to do something else first. Then you come back to > it (ESC k k ...), remove the # sign, finish typing the command, and run > it. But the backticked command was already executed much earlier than > you might have wished (two commands ago). Here's another argument why I feel that completion should NEVER rewrite your command line (not even to replace `pwd` with its value): I have been known to do things like this for testing parallel development trees: cd ~/dir run tests via a single command HOME=/path/to/alternate/ (to rerun cd) (to rerun tests, in a different directory) As long as tab completion on the cd command preserved the ~, then this scenario works. But as soon as completion "helpfully" rewrites ~ into /path/to/home, it breaks my work flow. Okay, so that work flow of abusing the definition of $HOME to swap between parallel work trees might not be the most common, but I hope it points out to you why completion should not be in the business of rewriting users commands, but only appending completions. And it can be applied to any other situation (substitute ~/$HOME with your choice of shell variable - if completion ever rewrites a command line with the expansion of $var rather than keeping literal $var in place, then you cannot alter $var in between repetitions of a command - even if completion had to temporarily expand $var in order to form better context about what I was completing after the point that $var appeared in my command line). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Command substitution (backtick) and tab completion
On Jan 5, 12:18 pm, Eric Blake wrote: > On 01/05/2011 09:57 AM, Greg Wooledge wrote: > > > > > On Wed, Jan 05, 2011 at 08:21:18AM -0800, chengiz wrote: > >> So if I get this right, the only time this is a problem is when the > >> command substitution runs more than once. > > > I'd actually characterize it differently: it's unsafe to run arbitrary > > commands during tab completion, because bash doesn't know what those > > commands might do. > > >> When does this happen? Not > >> in my "ls `pwd`/" example where the command runs once and > >> replaces itself with its output. Does it only run more than once when > >> the ticks are not complete? > > > You might realize you made a mistake, hit Ctrl-U, and start over. But > > the backticked command has already been executed. > > > You might hit ESC # to comment out the command line because you suddenly > > realize that you need to do something else first. Then you come back to > > it (ESC k k ...), remove the # sign, finish typing the command, and run > > it. But the backticked command was already executed much earlier than > > you might have wished (two commands ago). > > Here's another argument why I feel that completion should NEVER rewrite > your command line (not even to replace `pwd` with its value): > > I have been known to do things like this for testing parallel > development trees: > > cd ~/dir > run tests via a single command > HOME=/path/to/alternate/ > (to rerun cd) > (to rerun tests, in a different directory) > > As long as tab completion on the cd command preserved the ~, then this > scenario works. But as soon as completion "helpfully" rewrites ~ into > /path/to/home, it breaks my work flow. Okay, so that work flow of > abusing the definition of $HOME to swap between parallel work trees > might not be the most common, but I hope it points out to you why > completion should not be in the business of rewriting users commands, > but only appending completions. And it can be applied to any other > situation (substitute ~/$HOME with your choice of shell variable - if > completion ever rewrites a command line with the expansion of $var > rather than keeping literal $var in place, then you cannot alter $var in > between repetitions of a command - even if completion had to temporarily > expand $var in order to form better context about what I was completing > after the point that $var appeared in my command line). > Thanks for the detailed responses. They shed a lot of light on the issue. I will probably use variables instead of backticks and PROMPT_COMMAND to set the variables.
Memory leak in brace expansion
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 sasaka.net 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC
2010 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.1
Patch Level: 5
Release Status: release
Description:
It seems that there is memory leak in brace expansion. The memory used by
bash interpreter gets larger and larger when running this script:
#!/bin/bash
foo=bar.txt
while true
do
echo ${foo##*.}
done
However, the program works fine should the brace expansion be changed to
${foo}. So, the cause of the leak must be at the ${foo##*.}
Repeat-By:
Run this script:
#!/bin/bash
foo=bar.txt
while true
do
echo ${foo##*.}
done
-x test always succeeds for root on Solaris
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: solaris2.11
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='solaris2.11' -DCONF_MACHTYPE='i386-pc-solaris2.11'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -DSOLARIS -I. -I. -I./include -I./lib -g -O2
uname output: SunOS monkey.headgear.org 5.11 snv_151a i86pc i386 i86pc
Machine Type: i386-pc-solaris2.11
Bash Version: 4.1
Patch Level: 9
Release Status: release
Description:
On Solaris 11, when root (as after 'su -' or from cron) uses bash's built-in
test to test for executability, it always succeeds, even when the file is
not executable. This is because sh_eaccess() ends up calling access(2),
which is basically documented to have this behavior.
I saw this on the 4.0.28 that ships with Solaris 11 Express (11/10), as well
as a 4.0 that I built from source and a 4.1.9 that I built from source.
The problem is not present in the bash 3.00.16 that I've got on one of
our Solaris 10 systems, so I'll be filing a bug with them as well.
Repeat-By:
monkey 16:49 /var/tmp # touch normal-file
monkey 16:49 /var/tmp # ls -l normal-file
-rw-r--r-- 1 root root 0 Jan 4 16:49 normal-file
monkey 16:49 /var/tmp # bash -c '[ -x normal-file ] && echo bad || echo no
problem'
bad
monkey 16:49 /var/tmp # su cloyce -c "bash -c '[ -x normal-file ] && echo bad
|| echo no problem'"
no problem
Fix:
The patch below "fixes" the problem. There are probably some
subtleties that escape me, though.
--- lib/sh/eaccess.c.orig 2011-01-04 16:50:19.902373804 -0800
+++ lib/sh/eaccess.c2011-01-04 16:51:59.704669572 -0800
@@ -206,6 +206,7 @@
#elif defined (EFF_ONLY_OK)/* SVR4(?), SVR4.2 */
return access (path, mode|EFF_ONLY_OK);
#else
+ if (current_user.uid != 0 && current_user.euid != 0) {
if (mode == F_OK)
return (sh_stataccess (path, mode));
@@ -216,6 +217,7 @@
if (current_user.uid == current_user.euid && current_user.gid ==
current_user.egid)
return (access (path, mode));
+ }
return (sh_stataccess (path, mode));
#endif
Re: Memory leak in brace expansion
> 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 sasaka.net 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC > 2010 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 4.1 > Patch Level: 5 > Release Status: release > > Description: > It seems that there is memory leak in brace expansion. The memory used by > bash interpreter gets larger and larger when running this script: Thanks for the report. This has been fixed for the next version. 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: -x test always succeeds for root on Solaris
> Machine Type: i386-pc-solaris2.11 > > Bash Version: 4.1 > Patch Level: 9 > Release Status: release > > Description: > On Solaris 11, when root (as after 'su -' or from cron) uses bash's built-in > test to test for executability, it always succeeds, even when the file is > not executable. This is because sh_eaccess() ends up calling access(2), > which is basically documented to have this behavior. Geez, I hate access. What a fundamentally flawed design. And yet implementors keep stuffing more and more functionality into it (e.g., ACLs), requiring its use, though you can only trust it when it fails. Even faccessat is no help. Saying "yeah, there are a lot of bad access(2) implementations out there" might be true, but doesn't help me very much. This has been discussed extensively several times, most recently in July, 2010. 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: The translated command synopsises are never used
> Bash Version: 4.1 > Patch Level: 7 > Release Status: release > > Description: > The translated versions of the command synopsises (short_doc) > are never used. Thanks for the report. As I recall, there was some reason I didn't make this change before, but we'll try it now and see what happens. 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/
