RE: mdate-sh borks on uid/gid containing a space

[Dave Korn]

On 29 March 2007 16:27, Stepan Kasal wrote:

> Hello again,
> 
> On Thu, Mar 29, 2007 at 04:12:11PM +0100, Dave Korn wrote:
>> On 29 March 2007 15:38, Stepan Kasal wrote:
>>> On Thu, Mar 29, 2007 at 12:40:12AM +0100, Dave Korn wrote:
 On 29 March 2007 00:26, Ralf Wildenhues wrote:
>

> Eric's patch seems to indicate that line 92 needs changed, too.
> [...]
>>> So it is safer to use -n with ls /, too.
>> 
>>   Umm, yes, that's true, but not relevant; what I was pointing out is that
>> the -n gets added to the $ls_command variable, so it would already be
>> included in the command invoked on line 92, and if you take a second look
>> at the patch, you'll notice that the change to line 92 isn't about adding
>> -n, it's about taking away -l and -d.
> 
> I took a second look, and it did not help:
> 
> @@ -89,7 +93,7 @@
>  # words should be skipped to get the date.
> 
>  # On HPUX /bin/sh, "set" interprets "-rw-r--r--" as options, so the "x"
> below.
> -set x`ls -l -d /`
> +set x`$ls_command /`

  Gah, I overlooked that the original version wasn't using ls_command in the
first place.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: mdate-sh borks on uid/gid containing a space

[Stepan Kasal]

Hello again,

On Thu, Mar 29, 2007 at 04:12:11PM +0100, Dave Korn wrote:
> On 29 March 2007 15:38, Stepan Kasal wrote:
> > On Thu, Mar 29, 2007 at 12:40:12AM +0100, Dave Korn wrote:
> >> On 29 March 2007 00:26, Ralf Wildenhues wrote:
> >>> 
> >>> Eric's patch seems to indicate that line 92 needs changed, too.
[...]
> > So it is safer to use -n with ls /, too.
> 
>   Umm, yes, that's true, but not relevant; what I was pointing out is that the
> -n gets added to the $ls_command variable, so it would already be included in
> the command invoked on line 92, and if you take a second look at the patch,
> you'll notice that the change to line 92 isn't about adding -n, it's about
> taking away -l and -d.

I took a second look, and it did not help:

@@ -89,7 +93,7 @@
 # words should be skipped to get the date.

 # On HPUX /bin/sh, "set" interprets "-rw-r--r--" as options, so the "x" below.
-set x`ls -l -d /`
+set x`$ls_command /`

 # Find which argument is the month.
 month=

Cheers,
Stepan

RE: mdate-sh borks on uid/gid containing a space

[Dave Korn]

On 29 March 2007 15:38, Stepan Kasal wrote:

> Hello,
> 
> On Thu, Mar 29, 2007 at 12:40:12AM +0100, Dave Korn wrote:
>> On 29 March 2007 00:26, Ralf Wildenhues wrote:
>>

>>> Eric's patch seems to indicate that line 92 needs changed, too.
>>> (I haven't tested any on w32.)
>> 
>>   I don't quite understand that myself; ISTM that having -n in $ls_command
>> should do the job for both cases.
> 
> A wild guess:
> 
> Though the current situation is this (quoting Eric):
> 
> $ \ls -ld /
> drwxrwx---+ 14 eblake Users 0 Feb  2 07:58 /
> $ \ls -lLd doc/m4.texinfo
> -rw-r--r-- 1 eblake Domain Users 221922 Mar  1 14:50 doc/m4.texinfo
> 
> it might be possible that even the user or group owner of / would
> have a blank it its name.  (With Cygwin, one never knows.)
> 
> So it is safer to use -n with ls /, too.

  Umm, yes, that's true, but not relevant; what I was pointing out is that the
-n gets added to the $ls_command variable, so it would already be included in
the command invoked on line 92, and if you take a second look at the patch,
you'll notice that the change to line 92 isn't about adding -n, it's about
taking away -l and -d.

  Ah, hang on, now I see why; those flags are /also/ already included in
$ls_command, so they're superfluous on line 92; it's just a minor tidy up.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: mdate-sh borks on uid/gid containing a space

[Stepan Kasal]

Hello,

On Thu, Mar 29, 2007 at 12:40:12AM +0100, Dave Korn wrote:
> On 29 March 2007 00:26, Ralf Wildenhues wrote:
> 
> > Eric's patch seems to indicate that line 92 needs changed, too.
> > (I haven't tested any on w32.)
> 
>   I don't quite understand that myself; ISTM that having -n in $ls_command
> should do the job for both cases.

A wild guess:

Though the current situation is this (quoting Eric):

$ \ls -ld /
drwxrwx---+ 14 eblake Users 0 Feb  2 07:58 /
$ \ls -lLd doc/m4.texinfo
-rw-r--r-- 1 eblake Domain Users 221922 Mar  1 14:50 doc/m4.texinfo

it might be possible that even the user or group owner of / would
have a blank it its name.  (With Cygwin, one never knows.)

So it is safer to use -n with ls /, too.

Just guessing, I'm not a Cygwin user.

Stepan Kasal

RE: mdate-sh borks on uid/gid containing a space

[Dave Korn]

On 29 March 2007 00:26, Ralf Wildenhues wrote:

> Hi Dave,
> 
> * Dave Korn wrote on Wed, Mar 28, 2007 at 07:01:59PM CEST:
>> 
>>   As the subject line says, mdate-sh can get badly confused if there are
>> spaces in the textual version of the uid or gid.
> 
> Yep:
>

> Eric's patch seems to indicate that line 92 needs changed, too.
> (I haven't tested any on w32.)

  I don't quite understand that myself; ISTM that having -n in $ls_command
should do the job for both cases.
 
> It would surely be helpful to know whether we can assume -n to work
> portably and avoid the test (we test for -L which is POSIX, too).

  Well, to be fair it's a lot safer to test for it, and since this script may
only be invoked once in a very rare while, I don't suppose it's that important
to optimise every last bit out of it.  I'd like to hear Eric's rationale about
the line 92 change, but I reckon his patch is probably safer.

  He remembered to update the scriptversion and copyright lines, too!  :)

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: mdate-sh borks on uid/gid containing a space

[Ralf Wildenhues]

Hi Dave,

* Dave Korn wrote on Wed, Mar 28, 2007 at 07:01:59PM CEST:
> 
>   As the subject line says, mdate-sh can get badly confused if there are
> spaces in the textual version of the uid or gid.

Yep:

Eric's patch seems to indicate that line 92 needs changed, too.
(I haven't tested any on w32.)

It would surely be helpful to know whether we can assume -n to work
portably and avoid the test (we test for -L which is POSIX, too).

Cheers,
Ralf