Style question: Can this be written in a more elegant way?

Style question: Can this be written in a more elegant way?

[Com MN PG P E B Consultant 3]

Problem: In a directory, perform a certain operation PROG_SUCCESS on the
newest file
matching the glob pattern X*. If no file exists with this glob pattern,
execute PROG_FAIL.

Here is my solution:

file=$(ls -1t X* 2>/dev/null|head -n 1)
if [[ ${#file} -gt 0 ]]
then
  PROG_SUCCESS $file
else
  PROG_FAIL
fi

This certainly works, and I think it's not that bad either. Just
wondering whether
this can be written less clumsy. Any suggestions?

Ronald
-- 
Ronald Fischer (phone +49-89-63676431)
mailto:mn-pg-p-e-b-consultant-3.com@siemens.com

Re: Style question: Can this be written in a more elegant way?

[Marc Chantreux]

Com MN PG P E B Consultant 3 wrote:
> Here is my solution:

Here is mine but i'm sure there is faster.

file=( *(om) )
((  $file[1] )) && PROG_SUCCESS || PROG_FAIL

Re: Style question: Can this be written in a more elegant way?

[Bart Schaefer]

On Apr 24, 10:27am, Marc Chantreux wrote:
}
} Here is mine but i'm sure there is faster.
} 
} file=( *(om) )
} ((  $file[1] )) && PROG_SUCCESS || PROG_FAIL

I think you mean:

    file=( X*(Nom[1]) )
    (( $+file )) && PROG_SUCCESS $file || PROG_FAIL

However, that will run PROG_FAIL if PROG_SUCCESS fails, as well as if
there are no matching files.  I don't think you can avoid if/else.

    if (( $+file )); then PROG_SUCCESS $file; else PROG_FAIL; fi

Note that in the event that there are two or more files with the same
time stamp, there's no guarantee which one of them is chosen, and in
fact X*(om[1]) and X*(Om[1]) might both choose the same file.

Re: Style question: Can this be written in a more elegant way?

[Marc Chantreux]

Hi Bart,


> } file=( *(om) )
> } ((  $file[1] )) && PROG_SUCCESS || PROG_FAIL
> 
> I think you mean:
> 
>     file=( X*(Nom[1]) )
>     (( $+file )) && PROG_SUCCESS $file || PROG_FAIL

I didn't : my lines was the best i've found.
- haven't thought about the N modifier
- I've tried something like *(om)[1,2] but it naturally failed. didn't 
found the ([x]) in the doc.

but now i'll do mean!

> However, that will run PROG_FAIL if PROG_SUCCESS fails, as well as if
> there are no matching files.  I don't think you can avoid if/else.
> 
>     if (( $+file )); then PROG_SUCCESS $file; else PROG_FAIL; fi

i have noticed that a lot of people here don't use the alternative form. 
is there a reason to not use the next line ?

if (( $+file )) { PROG_SUCCESS $file } else { PROG_FAIL }

BTW, i've tried another way to launch PROG_SUCCESS for the first file 
but it failed because it execute the e:: code for all the files. Peraps 
there is a trick i missed?

% ls
is  score  the  this
% : *(Nom[1]e:echo last file $REPLY:)
last file score
last file score
last file score
last file score


regards
mc

Re: Style question: Can this be written in a more elegant way?

[Bart Schaefer]

On Apr 25,  9:55am, Marc Chantreux wrote:
} Subject: Re: Style question: Can this be written in a more elegant way?
} 
} > } file=( *(om) )
} > } ((  $file[1] )) && PROG_SUCCESS || PROG_FAIL
} > 
} > I think you mean:
} > 
} >     file=( X*(Nom[1]) )
} >     (( $+file )) && PROG_SUCCESS $file || PROG_FAIL
} 
} I didn't : my lines was the best i've found.

But (( $file[1] )) can't be right; it treats the file name as a math
expression, so a file named "3-3" would execute PROG_FAIL.  You must
at least mean (( ${+file[1]} )).

} is there a reason to not use the next line ?
} 
} if (( $+file )) { PROG_SUCCESS $file } else { PROG_FAIL }

It's a syntax error in other Bourne-like shells, and some of us are
habituated to write the portable constructs even when we're mixing
them with non-portable ones.
 
} BTW, i've tried another way to launch PROG_SUCCESS for the first file 
} but it failed because it execute the e:: code for all the files. Peraps 
} there is a trick i missed?

No, the meaning of (e:...:) is that the result of executing the commands
determines whether or not the file participates in the glob result.  So
the commands must be executed for every file, and this happens before
the sorting.

In this example ...

} % ls
} is  score  the  this
} % : *(Nom[1]e:echo last file $REPLY:)
} last file score
} last file score
} last file score
} last file score

... you have failed to quote $REPLY so it substitutes the value that it
had before the glob began to execute.  It's as if you had typed:

% : *(Nom[1]e:echo last file score:)

Correct is like so:

% : *(Nom[1]e:'echo last file $REPLY':)
last file this
last file is
last file the
last file score

Re: Style question: Can this be written in a more elegant way?

[Marc Chantreux]

Bart Schaefer wrote:
> But (( $file[1] )) can't be right; it treats the file name as a math
> expression, so a file named "3-3" would execute PROG_FAIL.  You must
> at least mean (( ${+file[1]} )).

oopps ... that was forgotten when copy/paste ...


> ... you have failed to quote $REPLY so it substitutes the value that it
> had before the glob began to execute.  It's as if you had typed:
> 
> % : *(Nom[1]e:echo last file score:)
> 
> Correct is like so:
> 
> % : *(Nom[1]e:'echo last file $REPLY':)
> last file this
> last file is
> last file the
> last file score

i got the first error ... but what i expect is to treat only the nth 
element of the list.

% : *(Nom[1]e:'echo last file $REPLY':)
last file this
% : *(Nom[2]e:'echo last file $REPLY':)
last file is
...

and so on ...

regards.
mc

Re: Style question: Can this be written in a more elegant way?

[Bart Schaefer]

On Apr 25,  4:58pm, Marc Chantreux wrote:
}
} what i expect is to treat only the nth element of the list.

Yes, I know, but I explained why that doesn't happen:

> the meaning of (e:...:) is that the result of executing the commands
> determines whether or not the file participates in the glob result.  So
> the commands must be executed for every file, and this happens before
> the sorting.

If it happens before sorting, it must also happen before selecting any
of the elements from the sorted result.

RE: Style question: Can this be written in a more elegant way?

[Com MN PG P E B Consultant 3]

> I think you mean:
> 
>     file=( X*(Nom[1]) )
>     (( $+file )) && PROG_SUCCESS $file || PROG_FAIL
> 
> However, that will run PROG_FAIL if PROG_SUCCESS fails, as well as if
> there are no matching files.  I don't think you can avoid if/else.
> 
>     if (( $+file )); then PROG_SUCCESS $file; else PROG_FAIL; fi
> 
> Note that in the event that there are two or more files with the same
> time stamp, there's no guarantee which one of them is chosen, and in
> fact X*(om[1]) and X*(Om[1]) might both choose the same file.

Thank you. This ambiguity would not be a problem in my case. Just out of
curiosity:

[OT] How exact are time stamps on files? If, basically, a time_t value
is choosen
for a time stamp, then in practice the only possibility for two files to
come
up with the same time stamp, is when the time stamp is explicitly
supplied
via "touch", isn't it?

Ronald
-- 
Ronald Fischer (phone +49-89-63676431)
mailto:mn-pg-p-e-b-consultant-3.com@siemens.com

Re: Style question: Can this be written in a more elegant way?

[Marc Chantreux]

> [OT] How exact are time stamps on files?

man stat

> If, basically, a time_t value
> is choosen
> for a time stamp, then in practice the only possibility for two files to
> come
> up with the same time stamp, is when the time stamp is explicitly
> supplied
> via "touch", isn't it?
> 
> Ronald

I think you're right but i'm not an expert.

i've tried something like :

echo content >a >b ; stat a b

the Access timestamps are the same, modify one are differents.

regards
mc

Re: Style question: Can this be written in a more elegant way?

[Bart Schaefer]

On Apr 25, 10:01am, Marc Chantreux wrote:
} Subject: Re: Style question: Can this be written in a more elegant way?
} 
} > [OT] How exact are time stamps on files?
} 
} man stat

That's not very helpful.  "man 2 stat" might be better, but not much.  On
my system, neither of them explains what a time_t represents.

The stored accuracy of file time stamps varies by operating system
implementation.  For practical shell programming purposes, though, it
has one-second granularity.  Modern computers can create or modify a
lot of files in one second.
 
} > If, basically, a time_t value is choosen for a time stamp, then in
} > practice the only possibility for two files to come up with the
} > same time stamp, is when the time stamp is explicitly supplied via
} > "touch", isn't it?
} 
} I think you're right but i'm not an expert.

Even if you're somehow prevented from writing more than one file per
second, there are a LOT of ways two files could get the same stamp.
Just a few I can think of immediately:
 - hard-link a file to a second name with "ln"
 - copy a file with "cp -a" or "tar" etc.
 - set the system clock back (e.g., ntpd adjusting for drift)