Re: [PATCH] when using `which` send errors to /dev/null

On Wednesday, 23 May 2007 at 18:48, Luciano Rocha wrote: > # HG changeset patch > # User [EMAIL PROTECTED] > # Date 1179846675 -3600 > # Node ID 357b7651d6095f5b2e9c5dab1e4cb5c7fb6bc379 > # Parent 516f41633e202184e897bef24a6d9f17bba7c0ba > when using `which` send errors to /d

Re: when using `which` send errors to /dev/null

On 2007-05-27 08:26:53 +1000, Cameron Simpson wrote: > On 26May2007 18:37, Vincent Lefevre <[EMAIL PROTECTED]> wrote: > | On 2007-05-26 21:56:35 +1000, Cameron Simpson wrote: > | > Of course, such a system isn't a UNIX system... > | > | Is there any reason why Mutt should not run on non-UNIX syste

Re: when using `which` send errors to /dev/null

On 26May2007 18:37, Vincent Lefevre <[EMAIL PROTECTED]> wrote: | On 2007-05-26 21:56:35 +1000, Cameron Simpson wrote: | > Of course, such a system isn't a UNIX system... | | Is there any reason why Mutt should not run on non-UNIX systems? I can think of numerous things that might fail: maildir fi

Re: when using `which` send errors to /dev/null

On 2007-05-26 21:56:35 +1000, Cameron Simpson wrote: > Of course, such a system isn't a UNIX system... Is there any reason why Mutt should not run on non-UNIX systems? -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 100% accessible validated (X)HTML - Blog:

Re: when using `which` send errors to /dev/null

On 26May2007 12:49, Vincent Lefevre <[EMAIL PROTECTED]> wrote: | On 2007-05-25 12:06:26 -0400, Derek Martin wrote: | > I'm not aware of any Unix-derivative systems where /bin/sh is | > not a Bourne-shell derivative (Bourne Shell, Korn Shell, POSIX shell, | > or Bash). All of those shells use ':' a

Re: when using `which` send errors to /dev/null

On 2007-05-25 12:06:26 -0400, Derek Martin wrote: > I'm not aware of any Unix-derivative systems where /bin/sh is > not a Bourne-shell derivative (Bourne Shell, Korn Shell, POSIX shell, > or Bash). All of those shells use ':' as the path separator for > $PATH. Can you suggest an example? It seem

Re: when using `which` send errors to /dev/null

On Fri, May 25, 2007 at 11:24:19AM +0200, Vincent Lefevre wrote: > On 2007-05-24 10:28:35 -0500, David Champion wrote: > > PATH_SEPARATOR does not exist in a Bourne shell. It may be POSIX, but > > only a few shells are indeed POSIX; whereas the convention for calling a > > shell script does not sp

Re: [PATCH] when using `which` send errors to /dev/null

On Thu, May 24, 2007 at 07:57:45 +0100, David Laight wrote: > Except that &> isn't posix-compliant shell syntax (it is from csh), and > isn't supported by all shells. Except that some standard (i.e. #!/bin/sh) shells are _not_ POSIX, such as on Solaris. That was already mentioned somewhere else in

Re: when using `which` send errors to /dev/null

On 2007-05-24 10:28:35 -0500, David Champion wrote: > PATH_SEPARATOR does not exist in a Bourne shell. It may be POSIX, but > only a few shells are indeed POSIX; whereas the convention for calling a > shell script does not specify POSIX shells, only /bin/sh. PATH_SEPARATOR is user code only. Not

Re: when using `which` send errors to /dev/null

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,

Re: when using `which` send errors to /dev/null

* 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

Re: when using `which` send errors to /dev/null

* 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

Re: when using `which` send errors to /dev/null

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

Re: when using `which` send errors to /dev/null

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

Re: [PATCH] when using `which` send errors to /dev/null

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

Re: [PATCH] when using `which` send errors to /dev/null

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

Re: when using `which` send errors to /dev/null

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: > >

Re: [PATCH] when using `which` send errors to /dev/null

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 by all shells. Also, since the redirection of {...} will enforce a subsh

Re: when using `which` send errors to /dev/null

* 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: > > printf "%s\n" "$PATH" | tr : '\012' | while read -r dir; do An

Re: when using `which` send errors to /dev/null

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 breaks on Solaris, which it may:-( | | I don't think -r i

Re: when using `which` send errors to /dev/null

* 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 breaks on Solaris, which it may:-( I don't think -r is present in a strict Bourne shell's "read". Solaris's gives "-r:

Re: when using `which` send errors to /dev/null

On 23May2007 20:22, Luciano Rocha <[EMAIL PROTECTED]> wrote: | if echo | md5sum &> /dev/null; then "&>" is not portable. It's a bastard import into bash from csh:-( Just go ">/dev/null 2>&1". Portable and just as readable. -- Cameron Simpson <[EMAIL PROTECTED]> DoD#743 http://www.cskk.ezoshosting

Re: when using `which` send errors to /dev/null

On 23May2007 13:33, David Champion <[EMAIL PROTECTED]> wrote: | Is the problem with irregular behavior of different whiches? I've never trusted it even to exist everywhere:-) | Which is | convenient but besides this has the drawback that since it's almost | always a csh script, it sometimes retur

Re: [PATCH] when using `which` send errors to /dev/null

On Wed, May 23, 2007 at 10:01:37PM +0200, Rado S wrote: > =- Luciano Rocha wrote on Wed 23.May'07 at 20:22:32 +0100 -= > > > > It's easy enough to add a which-like command though. > > > > What about stopping to find where the binary is and check only if it can > > be run? > > if echo | md5sum &>

Re: [PATCH] when using `which` send errors to /dev/null

=- Luciano Rocha wrote on Wed 23.May'07 at 20:22:32 +0100 -= > > It's easy enough to add a which-like command though. > > What about stopping to find where the binary is and check only if it can > be run? > if echo | md5sum &> /dev/null; then > MD5=md5sum > elif echo | md5 &> /dev/null; then >

Re: [PATCH] when using `which` send errors to /dev/null

On Wed, May 23, 2007 at 01:33:56PM -0500, David Champion wrote: > * On 2007.05.23, in <[EMAIL PROTECTED]>, > * "Rado S" <[EMAIL PROTECTED]> wrote: > > =- Luciano Rocha wrote on Wed 23.May'07 at 18:48:01 +0100 -= > > > > > when using `whic

Re: [PATCH] when using `which` send errors to /dev/null

* On 2007.05.23, in <[EMAIL PROTECTED]>, * "Rado S" <[EMAIL PROTECTED]> wrote: > =- Luciano Rocha wrote on Wed 23.May'07 at 18:48:01 +0100 -= > > > when using `which` send errors to /dev/null > > {...} > > -if test -x "`which md5`&quo

Re: [PATCH] when using `which` send errors to /dev/null

=- Luciano Rocha wrote on Wed 23.May'07 at 18:48:01 +0100 -= > when using `which` send errors to /dev/null > {...} > -if test -x "`which md5`" > +if test -x "`which md5 2> /dev/null`" On solaris 8 which produces noise on STDOUT, not STDERR. Maybe the a

[PATCH] when using `which` send errors to /dev/null

# HG changeset patch # User [EMAIL PROTECTED] # Date 1179846675 -3600 # Node ID 357b7651d6095f5b2e9c5dab1e4cb5c7fb6bc379 # Parent 516f41633e202184e897bef24a6d9f17bba7c0ba when using `which` send errors to /dev/null diff -r 516f41633e20 -r 357b7651d609 hcachever.sh --- a/hcachever.sh Sun May