On 2007-05-24 08:24:32 +0200, Ralf Wildenhues wrote:
> * Cameron Simpson wrote on Thu, May 24, 2007 at 01:31:31AM CEST:
> > On 23May2007 13:33, David Champion <[EMAIL PROTECTED]> wrote:
> >
> > | {
> > | echo $PATH | tr : '\012' | while read dir; do
> >
> > This is more robustly written:
> >
On Thu, May 24, 2007 at 07:57:45AM +0100, David Laight wrote:
> On Wed, May 23, 2007 at 10:55:25PM +0100, Luciano Rocha wrote:
> >
> > } 3>&2 > /dev/null 2>&1 (or 3>&2 &> /dev/null) should work instead.
>
> Except that &> isn't posix-compliant shell syntax (it is from csh), and
> isn't supported
On 2007-05-24 08:44:10 +0100, Luciano Rocha wrote:
> On Thu, May 24, 2007 at 07:57:45AM +0100, David Laight wrote:
> > Also, since the redirection of {...} will enforce a subshell (at least
> > on some shells), requesting it explicitly by using (...) is better.
>
> But then, the var assignment wil
On Wed, 23 May 2007, Kyle Wheeler wrote:
On Monday, May 21 at 12:39 PM, quoth Kyle Wheeler:
On Monday, May 21 at 07:15 PM, quoth Christoph Berg:
I've updated Anatoly's patch from 2005 that adds mouse tracking using
slang/ncurses to mutt. With "set mouse" (unset by default) mutt will
react to b
On Monday, May 21, 2007 at 17:57:02 +0200, Rado Smiljanic wrote:
[binding comma]
> we have no idea how many people use any other potential key.
We may imagine. If we neglect the tradition about comma, we can
half-safely imagine that users bind any single free key more or less
equally. Fo
=- Alain Bench wrote on Thu 24.May'07 at 13:59:13 +0200 -=
> > ',' is not everybody's favourite position to use on the
> > keyboard, so examples are adapted.
>
> Yes, sure. But when examples bind say ",@r13on", that's not
> intented to be a key sequence typed by a human.
> IIRC the full story abo
On Thursday, May 24 at 02:40 PM, quoth Cameron Simpson:
On 23May2007 21:21, David Champion <[EMAIL PROTECTED]> wrote:
| * On 2007.05.23, in <[EMAIL PROTECTED]>,
| * "Cameron Simpson" <[EMAIL PROTECTED]> wrote:
| > printf "%s\n" "$PATH" | tr : '\012' | while read -r dir; do
| > Unless that bre
On Thursday, May 24 at 08:24 AM, quoth Ralf Wildenhues:
And even more robustly (and faster!) written like this:
save_IFS=$IFS
IFS=:
for dir in $PATH; do
IFS=$save_IFS
...
done
IFS=$save_IFS
No, that won't work, because when $IFS is expanded, it will become
this:
save_IFS=
Wh
* Kyle Wheeler wrote on Thu, May 24, 2007 at 04:27:10PM CEST:
> On Thursday, May 24 at 08:24 AM, quoth Ralf Wildenhues:
>>
>> save_IFS=$IFS
[...]
> No, that won't work, because when $IFS is expanded, it will become this:
>
> save_IFS=
No, it will work: The shell does no word splitting after v
* On 2007.05.24, in <[EMAIL PROTECTED]>,
* "Ralf Wildenhues" <[EMAIL PROTECTED]> wrote:
>
> Of course Vincent's remarks about $PATH_SEPARATOR is good.
Traditional Bourne shells (of which a System V shell is represetntative;
and this doesn't include only Solaris but also HP/Digital and IRIX
On 24May2007 08:11, Kyle Wheeler <[EMAIL PROTECTED]> wrote:
| What about:
| echo $PATH | while read -d : dir ; do
| ?
Whitespace in the $PATH may be mangled. This:
echo "$PATH"
will reserve that. I think -d (delimiter, yes?) is less portable than -r
(raw - don't parse backslashes).
Also,
11 matches
Mail list logo
