OH No! It's even worse! A file can be a "regular file" or a "regular *empty *file"!
I give up. On Sat, Nov 22, 2014 at 6:58 AM, David Braun <[email protected]> wrote: > 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 <[email protected]> > 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=%n >>> DST=%N" hello >>> SRC=hello >>> 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 >> >> >
