Re: [POSIX conformance] "." looks for file in the current directory
Stephane Chazelas wrote: On Tue, Jun 10, 2008 at 11:19:47AM -0400, Chet Ramey wrote: [...] So it is indeed a bug. Yes, it is. I fixed it the last time this came up, in January. [...] Thanks, It still seems to be there in 3.2.39 which seems to be the latest version or ftp.gnu.org. Yes, it is. This is not one of the released patches. If there's a newer version, where can it be found? Is there a CVS/git/svn repository with anonymous access available? http://cvs.savannah.gnu.org/viewvc/bash/?root=bash seems to be empty. There is no anonymous source code repository. Do you maintain the code under version control? I sometimes wonder when this or that feature has been added, it would be nice to have something like the cvs logs for that. Use the changelog in CWRU/changelog to find dates for new feature additions and bug fixes. Bug fix entries are usually annotated with the name and email address of the reporter. Chet Cheers, Stéphane -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Man page incorrect for "continue & break", "suspend" and "fg"
Roman Rakus wrote: I have found one message for this: http://lists.gnu.org/archive/html/bug-bash/2008-05/msg00074.html And I have added some others patches. Oh, 1 patch for this 3 things :) Please say if this patch will be applied. Thanks for the updates. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: heredoc in command subst bug?
Eric Blake wrote: I'm not sure whether this is a bug in POSIX or in bash, but I noticed the following with bash-3.2.39. $ bash -c 'foo=$(cat < I agree with your analysis. The reworked command-substitution parsing in bash-4.0 makes this a syntax error. Finally, bash has a definite bug, with no POSIX ambiguities: $ bash -c 'cat
Re: Function definition syntax inconsistencies
Jan Schampera wrote: When you use the third form shown above and use the subshell-grouping compound command '(...)' as function body, then it doesn't pass the parser: - $ function name (echo) bash: syntax error near unexpected token `echo' - That's the reason I think there's a bug, either in the description or in the code. Since the rest of the behaviour of function definitions is very consistent as described in the manual, I assume it's a bug in the code. It's not. It's a shift/reduce conflict in the grammar. The default yacc/bison behavior is to choose the `function word () command' production, and I have left it that way. The `function word command' form came from ksh, which doesn't allow the construct you used anyway (it requires one or more newlines after the word), so the current bash implementation supports all existing ksh uses. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: [doc] read -t and sockets, devices...
Stephane Chazelas wrote: However, I find that it does have an effect on Unix or TCP sockets, on /dev/random and other terminals than "the" terminal. So maybe a better wording could be: "This option has no effect on regular files"? Thanks, I'll put in something combining those two concepts. Also, it may be good to specify that, if the timeout is reached, bash will consume the input but will not put that consumed input into the variable: Actually, the bash-4.0 implementation will put the input read into the specified variable(s), but will still return failure if the timeout is hit. I think the best way to differentiate is to clear the variable before the call, then check the variable afterward. You can treat the read as having failed, but still use whatever data was read, if any. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Function definition syntax inconsistencies
Chet Ramey wrote:
>> -
>> $ function name (echo)
>> bash: syntax error near unexpected token `echo'
>> -
> It's not. It's a shift/reduce conflict in the grammar. The default
> yacc/bison behavior is to choose the `function word () command' production,
> and I have left it that way. The `function word command' form came from
> ksh, which doesn't allow the construct you used anyway (it requires one
> or more newlines after the word), so the current bash implementation
> supports all existing ksh uses.
Okay, then it could be mentioned in the manual (as exception or so, like
the semikolon in {...;} "for parsing reasons"). Some beginner pointed me
at this, thinking he made a mistake or didn't understand the manual.
Sorry for not providing a manpage patch.
--
This is my life - this is my net!
- Jan
Re: [doc] read -t and sockets, devices...
On Fri, Jun 13, 2008 at 06:52:48PM -0400, Chet Ramey wrote: [...] >> Also, it may be good to specify that, if the timeout is >> reached, bash will consume the input but will not put >> that consumed input into the variable: > > Actually, the bash-4.0 implementation will put the input read into > the specified variable(s), but will still return failure if the timeout > is hit. > > I think the best way to differentiate is to clear the variable before > the call, then check the variable afterward. You can treat the read > as having failed, but still use whatever data was read, if any. [...] Thanks, however in the: sleep 1 | bash -c 'read -t2' and sleep 2 | bash -c 'read -t1' case, that still won't help. The first case is eof, second is timeout. $REPLY will be empty in both cases, and 1 returned. What about a different $? (like 2 for timeout)? -- Stéphane
Bug on history control, don't erase no dups
Hello, I have the following lines on my login script, intended to make my history big enough for me, and not to waste space by keeping several copies of the same command again anda again: HISTCONTROL='ignoreboth:erasedups' HISTSIZE=4096 HISTFILESIZE=4096 To make sure it is working as that, I do (where "$" is shell prompt): $set | grep HIST This outputs: HISTCONTROL=ignoreboth:erasedups HISTFILE=/path/to/my/.bash_history HISTFILESIZE=4096 HISTSIZE=4096 Part of my history is, righ now: 522 cd /var/tmp/; touch z 523 cd /var/tmp/; touch z 524 ll 525 ssh zabu 526 ssh ximi 527 ls 528 ssh zabu 529 ssh ximi 530 gprolog 531 GLOBALZS=10 532 gprolog --q="[test]" 533 gprolog --q "[test]" 534 gprolog --q "[tp]" 535 ssh ximi As you see, there are several repeated lines. Many of them are commands I use constantly. I started with a clean history. But even if not, the duplicates should have been erased, as I understood from the manual page? I suspect that, if I am not making any stupid mistakes, is it because I use to keep several shells opened at once. I open and close them in a semi-chaotic fashion. Do you sugest anything, or is this really a bug? Also, you may give me some advice on how to reproduce the bug, if what I told isn't that usefull for finding the problem. Bashbug script didn't work for me. I think it couldn't find vim on the right place. I tried making a copy of the script and changing the path on the file (wich I thought to be trivial), but there is no "vim" written in there either, so I gave up. o:) Kindly, B
