Robert Elz via austin-group-l at The Open Group dixit:

>The non existing path version can just be done as:
>
>       var=/whatever/path/name  # obtained however this path is calculated
>       newpath=$(realpath ${var%/*})/${var##*/}

No, because the trailing /name *may* exist (and be a symlink).

>But I currently don't understand the point of canonicalising a
>path that doesn't exist (why not create it first, then get the
>canonical form?

Output filenames.

outf=$(realpath "$1")
dosomething >"$outf"

>  If it isn't to be created, and doesn't exist,
>then why does anyone care what its canonical name might be?)

set -- ./filename
outf=$(realpath "$1")
cd "$(realpath "$0/..")"        # or mktemp -d or something…
dosomething >"$outf"

This is something I do all the time.

>You do need (as do we all) to accept that sometimes complying with a new
>version of the standard is going to require implementation changes, right?

Yes. But I have hope that, if I argue my case sufficiently, the
new version of the standard will be made with my case in mind ;)

>That is, the plan would be
>to perhaps add the -e option (and maybe -q, and perhaps a newly invented -E),

Why?

Instead of -e, you can just do a subsequent test -e on the file.
Instead of -q, you can 2>/dev/null.

>and almost certainly to allow multiple file args

No, absolutely NOT that. That’s going to reopen the debate about
output separators (and only safe if NUL). And none of the existing
implementations has -0/-z/-Z.

I *did* think about this when adding realpath to mksh, and I decided
for handling exactly one argument precisely to avoid this hellhole.

bye,
//mirabilos
-- 
> Wish I had pine to hand :-( I'll give lynx a try, thanks.

Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine

              • ... Geoff Clare via austin-group-l at The Open Group
              • ... Geoff Clare via austin-group-l at The Open Group
              • ... Robert Elz via austin-group-l at The Open Group
          • ... Jonathan Wakely via austin-group-l at The Open Group
          • ... Robert Elz via austin-group-l at The Open Group
            • ... Jonathan Wakely via austin-group-l at The Open Group
              • ... Jonathan Wakely via austin-group-l at The Open Group
              • ... G. Branden Robinson via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • Re: [10... Robert Elz via austin-group-l at The Open Group
      • Re:... Thorsten Glaser via austin-group-l at The Open Group
      • Re:... Robert Elz via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • Re: [10... Quentin Rameau via austin-group-l at The Open Group
      • Re:... Eric Blake via austin-group-l at The Open Group
      • Re:... Robert Elz via austin-group-l at The Open Group
        • ... Jonathan Wakely via austin-group-l at The Open Group
          • ... Eric Blake via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to