Re: stat(1) print formats

[David Braun]

Assaf,

Nope - wrong button! Now you know why I don't play with things that shoot other things!

But my point is, it is far easier to add quoting and other text if needed than it is to remove. Even if the symlink's name and/or value aren't simple the user is the only one who really knows how the text from the stat command are to be used. Let her add quotes or side text as needed. The stat command is one of those utilities that report information so it can be used elsewhere. It has a default presentation for convenience but the output formatting mechanism is where a user can tailor the output. This should be simple and clean.

Also, where your example took 7 commands to produce the desire result mine took one and no parsing needed - not even trivial parsing! (btw - between bash and sed, getting all the quotes and escapes right is a royal pain)

Parsing stuff that is intended for eyeballs is always iffy as the locale problem here highlights.

Nope - your test example is circular - sorry - $SRC came from stat which also can report the file type. But now we're getting silly.

Hey - thanks for the discussion - I think the horse is dead at this point.

dave

I recall a system where everything was memory mapped and had a name so you could say

print hello$symlink[0]

to send the first character of the destination of the name of the thing pointed to by the file hello ...

On Fri, Nov 21, 2014 at 7:41 PM, Assaf Gordon <address@hidden> wrote:

Hello David,

You sent this message just to me.
Did you mean it as private or as a reply a coreutils' mailing list ?

In any case, - I'm answering in private,
but you are welcome to forward my reply to the mailing list.

On 11/21/2014 07:15 PM, David Braun wrote:

But I'd still like to argue for a simple %something that outputs just
the link destination/target/value (whatever you what to call it).
This would make the processing you suggested unnecessary. And I think
the current behavior produces something that isn't very useful to
start with.

That is up to the coreutils developers - I'm not one...

BTW - why did you make your example so darned difficult to read?!

:)

Yes, not only it was difficult to read, it was tricky to construct...

My point was to illustrate that quoting is used to remove ambiguity with symlinks.
if both the name of the src and dest are 'simple' (e.g. no special characters, no white space,
no quotes, no dash or less-than characters) then parsing using shell would be trivial (which is something you've asked about).

With my contrived example I hoped to show that even a complicated case can be parsed without ambiguity.
Perhaps I went too far...

Wouldn't it have been simpler (if not exhaustive) to have said

<...>

and proceed from there? While all the special characters in your
example may cover a lot of ... special cases they don't help
readability at this point in the discussion. Also my suggestion would
reduce you example to

Yes, I would have been simpler.
I probably should have started with a more approachable example.

But a simpler example would still leave open the question of what happens
if the filenames themselves have quotes - how does that work in conjunction with %N .
Or worse - if they have "->" in them...

Also my suggestion would reduce you example to

$ stat -tc "SRC=""> DST=%N" hello
SRC=""> DST=world

and the split command line is only because stat doesn't process
escapes like '\n'. This assumes that '-t' in combination with '-c'
makes %N return an unadorned (like %n) destination.

Agreed, if your suggestion is incorporated into a 'stat' option, that this would be much simpler.

However, I'm not sure 'stat' is the optimal tool for such things (especially if it depends on parsing the results, and making assumptions about file names).
Perhaps a better way would be to use
    test -h "$SRC" && DST=$(readlink -- "$SRC") || DST="$SRC"

Which will set DST to be either SRC (if it's a file), or resolve the symlink of SRC if it's a symlink.

Regards,
 - Assaf