Re: style of assignment to variable changes command selection
Bob Proulx wrote: > This implies to me that a variable assignment forces subsequent > commands to be external commands because the current environment is > not affected. In your case above the external /usr/bin/time program > is forced by the variable assignment requiring the environment > variable set for it. I think the hint is in the difference of a (grammar-)"pipeline" and a "simple command". The variable assignment to change the environment of the called program is part of the simple command. The time keyword is part of the pipeline syntax. I think the correct way to do that is: time X=x foocommand since X=x time foocommand implies that this is a simple command. Jan
Re: style of assignment to variable changes command selection
Doug McIlroy wrote: These two bash sequences are not equivalent. My intuition and the bash man page tell me they should be the same. % export X=x; time --version; unset X -bash: --version: command not found % unset X; X=x time --version GNU time 1.7 They are not the same, and should not be treated identically. Bash implements `time' as a reserved word, not a builtin. Reserved words are recognized by the grammar only in specific circumstances, and following an assignment statement isn't one of them. I implemented it as a reserved word to allow pipelines, and to a lesser extent, shell builtins, to be timed. There's really no reason to ever implement it as a regular builtin -- people just don't time builtins very often, and that's the only thing making it a builtin would buy you. Bash's implementation of time conforms to Posix, which explicitly allows it to be a reserved word. However, it is possible, and fairly easy, to configure bash without support for command timing. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: style of assignment to variable changes command selection
Eric Blake wrote: Re-adding the list - I am not the bash maintainer, so keeping the list in the loop is essential if you want any action taken. I am the bash maintainer, so I figure my opinion will count for something. | So there's a bug in the manual, which does not breathe a word about | time being executed by the shell. And the shell covers its tracks, too: I think the manual's pretty clear about where and how time is implemented. It's just not mentioned in the builtins section, since: | | % builtin time | bash: builtin: time: not a shell builtin it's not a builtin. | | Were I still the keeper of Unix manuals, my fix to the manual | would be to list this wart under BUGS. Ummm...why, exactly? The manual accurately describes the implementation, which conforms to the relevant standards. A Posix implementation may provide another version of time as a separate utility, which will accommodate your desired usage. Even something like #! /bin/sh time "$@" would suffice and allow builtins, if not pipelines, to be timed. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: SEGV on unbounded recursion
[EMAIL PROTECTED] wrote: 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-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 -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables uname output: Linux tjanouse.englab.brq.redhat.com 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:02 EDT 2007 i686 i686 i386 GNU/Linux Machine Type: i686-redhat-linux-gnu Bash Version: 3.2 Patch Level: 33 Release Status: release Description: Unbounded recursion results in a SEGV instead of some error message telling you what happened. And the test case I'm attaching could also just run forever if something like tail recursion was handled. I'm not inclined to change the current behavior. Bash is perfectly happy to allow people to shoot themselves in the foot. We all agree that fixed-limit recursion is not the way to go, and I don't think the effort involved in handling tail recursion is well spent. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
