On 24/06/17 17:02, Assaf Gordon wrote: > Hello all, > > I've encountered two interesting (?) edge-cases with realpath. > Perhaps they warrent a change in documentation (or even > error-checking code). > > First, > Running 'realpath' in a deleted (unlinked) directory leads to confusing > error messages. Example: > > # In terminal 1 > mkdir /tmp/a > cd /tmp/a > > # In another terminal > rmdir /tmp/a > > # back in terminal 1 > $ realpath /foo > /foo > > $ realpath foo > realpath: foo: No such file or directory > > $ realpath ../foo > realpath: ../foo: No such file or directory > > $ realpath -m foo > realpath: foo: No such file or directory > > I'd say this error message is confusing, because naively 'realpath' does > not require the last component to exist, and with '-m' it doesn't > require any component to exist. Yet the error message hints that > something that should exist doesn't. > > The reason for the error message is this flow: > src/realpath.c:process_path() > src/realpath.c:realpath_canon() > gnulib/lib/canonicalize.c:canonicalize_filename_mode() > gnulib/lib/xgetcwd.c:xgetcwd() > > Then xgetcwd fails (because the directory was deleted), > but despite the 'x' prefix, it only dies on ENOMEM, > not on ENOENT. It returns NULL, and the rest of the program > fails, but errno remains at ENOENT. > > Not sure what would be a good gnulib fix without breaking > existing code that uses 'canonicalize_filename_mode'. > > Of course, it is always recommended not to run programs > in a deleted directory... many programs will fail with confusing > errors.
Yes, it would be better to improve the error for this case to say we can't get the name of the _current directory_. > Second, > `realpath --help` shows: > --relative-to=FILE print the resolved path relative to FILE > --relative-base=FILE print absolute paths unless paths below FILE > > This hints (to a naive person like me :) ) that realpath will calculate > relative path to any file. But in fact, it assumes that the FILE > argument is always a directory, and with 'realpath -e' it indeeds > verifies it's a directory. > So perhaps just update the usage text? (patch attached). > If not, then add a new 'gotcha' ? > --- a/src/realpath.c > +++ b/src/realpath.c > @@ -81,8 +81,8 @@ all but the last component must exist\n\ > - --relative-to=FILE print the resolved path relative to FILE\n\ > - --relative-base=FILE print absolute paths unless paths below > FILE\n\ > + --relative-to=DIR print the resolved path relative to DIR\n\ > + --relative-base=DIR print absolute paths unless paths below DIR\n\ Yes this is clearer. Otherwise one might also think the FILE's directory is used. Please update the info doc also. thanks! Pádraig
