On Monday 29 June 2009 19:16:08 Chris Jones wrote:
> My guess is that the non-printable characters in my bash prompt that
> switch colors interfere with bash's notion of the prompt's length?
you really should post the PS1 value that is causing trouble. most likely you
didnt use \[...\] sequences
Not sure whether this is a bug in my version of bash, but I copied over
my colored PS1 prompts from debian etch - regular user & root - and some
convenient keyboard actions are misbehaving. After retrieving a command
from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to
somewhere in
Mike Frysinger wrote:
> On Monday 29 June 2009 04:54:52 Yang Zhang wrote:
>> Hi, I like using nounset for stricter scripts, but an annoyance is that
>> anytime I use "$@" and it's empty, I get an error, when (to me,
>> cognitively) it is not "unset" (as in someone *forgot* to set it), it's
>> just
On Monday 29 June 2009 14:38:34 Yang Zhang wrote:
> Mike Frysinger wrote:
> > does something like this at the top of the script work ?
> > [ $# -eq 0 ] && set --
>
> But I also would need that at the top of every function, right?
assuming this snippet actually helps, then probably. but it might b
Mike Frysinger wrote:
On Monday 29 June 2009 04:54:52 Yang Zhang wrote:
Hi, I like using nounset for stricter scripts, but an annoyance is that
anytime I use "$@" and it's empty, I get an error, when (to me,
cognitively) it is not "unset" (as in someone *forgot* to set it), it's
just an empty, w
Chet Ramey wrote:
> It depends on what you mean by `fail'.
> ...
> To do otherwise would have made expr much less useful. Idioms such as
Also I must mention grep too. The exit status of grep isn't just
whether it exits without an error but instead returns an indication of
whether the pattern mat
On Monday 29 June 2009 04:54:52 Yang Zhang wrote:
> Hi, I like using nounset for stricter scripts, but an annoyance is that
> anytime I use "$@" and it's empty, I get an error, when (to me,
> cognitively) it is not "unset" (as in someone *forgot* to set it), it's
> just an empty, which is a common
> and it's a bug that bash-4 is filtering them.
Maybe, maybe not. That's open to interpretation. Here's how I see it.
> not allowing them to be used in
> the shell is fine (echo ${vmlinux.lds}), but removing them from the
> environment and thus not allowing other applications to leverage the
> > echo `expr $var - 1`
> shrug. I didn't knew that either.
> I think that this is bad. expr should do some calculation. If the
> calculation fails (eg devision by zero) the return value should be non
> zero.
It depends on what you mean by `fail'. expr certainly returns a non-zero
result for th
On Mon, Jun 29, 2009 at 12:45:29AM +0200, Marc Weber wrote:
> > echo `expr $var - 1`
> I think that this is bad. expr should do some calculation. If the
> calculation fails (eg devision by zero) the return value should be non
> zero.
You'd think so, but alas, the people who made expr(1) had a diff
Hi Chet,
thanks for the patch. Tested both on x86
and sparc with no additional problem.
Sorry for inconvenience, it could have
been sorted out in patch 49.
Will this come out as patch 50?
Regards,
hnhn
Chet Ramey wrote:
Jan Hnatek wrote:
Chet Ramey wrote:
So what does the Solaris mbrtowc ret
Hi, I like using nounset for stricter scripts, but an annoyance is that
anytime I use "$@" and it's empty, I get an error, when (to me,
cognitively) it is not "unset" (as in someone *forgot* to set it), it's
just an empty, which is a common case (IIRC, in bash, variables set to
empty arrays and
12 matches
Mail list logo
