On 3/1/13 5:04 PM, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>> Your vendor, which may be SuSE, has changed bash and shipped the modified
>> version.
>
> Supposedly this has to do with memory corruption problems in
> 4.2 and the "possibility" that it might come back...
I think you mean bas
Chet Ramey wrote:
> Your vendor, which may be SuSE, has changed bash and shipped the modified
> version.
Supposedly this has to do with memory corruption problems in
4.2 and the "possibility" that it might come back...
Is this likely to be a problem?
Dr. Werner Fink wrote:
> The patch bel
Hi,
Is it possible to use the completion system to get a list of available
options for a command bash knows how to auto-complete?
Ideally, I'd like given the name of a program to get a list of pairs
(option string, desc) for each available option. I'd be nice to also
get options that are only ava
On 2/27/13 5:42 PM, Bob Proulx wrote:
> Chet Ramey wrote:
>> I don't know what version you're using; I have 0.11.
>>
>> $ ./posh
>> \[\]${HOST}($SHLVL)\$ exit 1
>> ./posh: exit: bad number
>>
>> $ ./posh
>> \[\]${HOST}($SHLVL)\$ exit 10
>> ./posh: exit: bad number
>> $ echo $?
>> 1
>
> I am using
On Friday, March 01, 2013 01:06:27 PM Thorsten Glaser wrote:
> Hrm, but the docs, both, specifically say that (unquoted) $@ behaves
> like $* except in the face of no arguments, so I cannot do that.
>
> But thanks for the feedback. My reading differed, but you have a
> point, and the others can be
Dan Douglas dixit:
>For "$@" that sounds about right. I think it would be preferable if x="$@" and
>x=$@ were the same. If a user wants IFS-delimited they should probably use
Hrm, but the docs, both, specifically say that (unquoted) $@ behaves
like $* except in the face of no arguments, so I ca
On Friday, March 01, 2013 11:49:37 AM Thorsten Glaser wrote:
> Dan Douglas dixit:
>
> >Well, ok then. I'm just nitpicking here. I think this makes sense because
> >distinguishes between $@ and $* when assigning to a scalar, so that the end
> >result of $@ is always space-separated, as spaces deli
Dan Douglas dixit:
>Well, ok then. I'm just nitpicking here. I think this makes sense because it
>distinguishes between $@ and $* when assigning to a scalar, so that the end
>result of $@ is always space-separated, as spaces delimit words during command
[…]
>Consider for example if you ever imp
