BUG: echo builtin does not handle -- arguments
in latest bash:
suppose script:
for i in ${filenam...@]}; do
echo $i
done
if malicious user give file name -e, empty string will be emitted to
stdout, but string -e should.
It will be nice if I cat write
echo -- $i
as many tool, such as grep, use.
Now, I replace echo $i with printf %s\n $i, but it is
workaround, as I think.
--
Segmentation fault
Re: BUG: echo builtin does not handle -- arguments
On 11/22/10 3:33 AM, Марк Коренберг wrote: It will be nice if I cat write echo -- $i as many tool, such as grep, use. Posix specifically says that echo does not honor `--'. -- ``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: ionice bash pid in bash_profile Fails
On Mon, Nov 22, 2010 at 08:39:49AM -0500, Greg Wooledge wrote: On Sun, Nov 21, 2010 at 04:08:33PM -0900, Roger wrote: When logging in, the following fails if put in $HOME/.bash_profile: ionice -c 2 -n 0 -p `pidof bash` ... I'm guessing, because bash hasn't started yet? I very much doubt you want to use `pidof bash` here. That would pick up EVERY bash process running on the system, including other people's, and possibly a few wrapper scripts running as root. If you want the PID of the current shell process, use $$ instead. Yes I do. It's only me on this computer, unless you're speculating on prioritizing a snooper. :-O Here's the error I get when logging into a virtual terminal and $HOME/.bash_profile executes or is read in: ionice: ioprio_set failed: No such process -- Roger http://rogerx.freeshell.org/
Re: ionice bash pid in bash_profile Fails
Roger wrote: If you want the PID of the current shell process, use $$ instead. Yes I do. It's only me on this computer, unless you're speculating on prioritizing a snooper. :-O This is (in this context) not related to the number pf bash processes running. Not at all. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Compiling Bash 2.05b (patched) gives error: label at end of compound statement [solved]
Compiling Bash 2.05b with seven patches applied. malloc.c: In function ‘internal_free’: malloc.c:881: error: label at end of compound statement make[1]: *** [malloc.o] Error 1 Adding a semicolon on the line after this label satisfies the picky gcc 4.4.1 (actually since 3.4?). This is just FYI for those who might need it.
Re: blink-matching-paren doesn't blink
On 11/22/10 3:36 PM, Dennis Williamson wrote: When I do bind -v one of the settings I see is set blink-matching-paren on It's not supposed to be enabled by default. (It's also not documented.) Since a function has to run to do the appropriate things when it's enabled, and isn't run until it's set explicitly, you don't get the right behavior even though readline tells you it's enabled. 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: Correct usage of F_SETFD
include/filecntl.h in bash-4.1 has following: #define SET_CLOSE_ON_EXEC(fd) (fcntl ((fd), F_SETFD, FD_CLOEXEC)) Is that really the correct/intended usage of F_SETFD ? If kernel ever adds a new flag to the fd, this would end up clearing the other new flag right ? Shouldn't bash use F_GETFD to get the current flags and set/clear just the FD_CLOEXEC bit ? Sukadev
Re: ionice bash pid in bash_profile Fails
On Mon, Nov 22, 2010 at 11:58:25AM -0500, Greg Wooledge wrote: On Mon, Nov 22, 2010 at 07:41:48AM -0900, Roger wrote: On Mon, Nov 22, 2010 at 08:39:49AM -0500, Greg Wooledge wrote: ionice -c 2 -n 0 -p `pidof bash` If you want the PID of the current shell process, use $$ instead. Here's the error I get when logging into a virtual terminal and $HOME/.bash_profile executes or is read in: ionice: ioprio_set failed: No such process Perhaps pidof fails to find the -bash process due to the leading dash? Who knows? Who cares? Use $$ to get the PID of the shell. The following works like a charm: # See ionice manfile - give high priority to Bash ionice -c 2 -n 0 -p `echo $$` Thanks! -- Roger http://rogerx.freeshell.org/
Re: ionice bash pid in bash_profile Fails
On Mon, Nov 22, 2010 at 12:44:54PM -0900, Roger wrote: ionice -c 2 -n 0 -p `echo $$` You don't need echo or `` here. ionice -c 2 -n 0 -p $$
Re: ionice bash pid in bash_profile Fails
On Mon, 22 Nov 2010, Roger wrote: On Mon, Nov 22, 2010 at 11:58:25AM -0500, Greg Wooledge wrote: On Mon, Nov 22, 2010 at 07:41:48AM -0900, Roger wrote: On Mon, Nov 22, 2010 at 08:39:49AM -0500, Greg Wooledge wrote: ionice -c 2 -n 0 -p `pidof bash` If you want the PID of the current shell process, use $$ instead. Here's the error I get when logging into a virtual terminal and $HOME/.bash_profile executes or is read in: ionice: ioprio_set failed: No such process Perhaps pidof fails to find the -bash process due to the leading dash? Who knows? Who cares? Use $$ to get the PID of the shell. The following works like a charm: # See ionice manfile - give high priority to Bash ionice -c 2 -n 0 -p `echo $$` Why are you using echo? ionice -c 2 -n 0 -p $$ -- Chris F.A. Johnson, http://cfajohnson.com Author: Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: bash: Correct usage of F_SETFD
include/filecntl.h in bash-4.1 has following: #define SET_CLOSE_ON_EXEC(fd) (fcntl ((fd), F_SETFD, FD_CLOEXEC)) Is that really the correct/intended usage of F_SETFD ? F_SETFDSet the close-on-exec flag associated with fildes to the low order bit of arg (0 or 1 as above). If kernel ever adds a new flag to the fd, this would end up clearing the other new flag right ? Shouldn't bash use F_GETFD to get the current flags and set/clear just the FD_CLOEXEC bit ? I suppose it would matter if there are systems that have more than one flag value. 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: blink-matching-paren doesn't blink
In Bash 4.1 downloaded and patched from the case.edu Bash site, when I do bind -v I see set blink-matching-paren on (and have non-working paren matching) without having changed any compile-time settings and with no corresponding command in any startup files. So I don't know how it got (half) enabled. On Mon, Nov 22, 2010 at 3:18 PM, Chet Ramey chet.ra...@case.edu wrote: On 11/22/10 3:36 PM, Dennis Williamson wrote: When I do bind -v one of the settings I see is set blink-matching-paren on It's not supposed to be enabled by default. (It's also not documented.) Since a function has to run to do the appropriate things when it's enabled, and isn't run until it's set explicitly, you don't get the right behavior even though readline tells you it's enabled. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
Re: blink-matching-paren doesn't blink
On 11/22/10 5:24 PM, Dennis Williamson wrote: In Bash 4.1 downloaded and patched from the case.edu Bash site, when I do bind -v I see set blink-matching-paren on (and have non-working paren matching) without having changed any compile-time settings and with no corresponding command in any startup files. So I don't know how it got (half) enabled. The controlling variable is mistakenly on by default. That doesn't work. 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: bash: Correct usage of F_SETFD
On 11/22/2010 03:16 PM, Chet Ramey wrote: include/filecntl.h in bash-4.1 has following: #define SET_CLOSE_ON_EXEC(fd) (fcntl ((fd), F_SETFD, FD_CLOEXEC)) Is that really the correct/intended usage of F_SETFD ? F_SETFDSet the close-on-exec flag associated with fildes to the low order bit of arg (0 or 1 as above). If kernel ever adds a new flag to the fd, this would end up clearing the other new flag right ? Shouldn't bash use F_GETFD to get the current flags and set/clear just the FD_CLOEXEC bit ? I suppose it would matter if there are systems that have more than one flag value. In practice, there aren't any such systems; but POSIX warns that current practice is no indicator of future systems, and that read-modify-write is the only way to use F_SETFD. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
