[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: relpath

From: Pádraig Brady
Subject: Re: PATCH: relpath
Date: Sat, 31 Dec 2011 10:45:56 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

On 12/31/2011 09:43 AM, Jim Meyering wrote:
> Pádraig Brady wrote:
>> On 12/12/2011 12:24 AM, Pádraig Brady wrote:
>>> FYI I'm not forgetting about this.
>>> This week I'll be travelling with work,
>>> but I intend to tackle this early the following week.
>> Sorry for the delay.
>> Attached is the realpath implementation, which I think
>> turned into a good cohesive set of functionality.
>> It has this interface:
> Thanks!
> I noticed a couple nits.
>> Usage: src/realpath [OPTION] FILE...
>> Print the resolved absolute file name;
>> all but the last component must exist
>>   -e, --canonicalize-existing  all components of the path must exist
>>   -m, --canonicalize-missing   no components of the path need exist
>>   -L, --logical                resolve `..' components before symlinks
>>   -P, --physical               resolve symlinks as encountered (default)
>>   -q, --quiet                  suppress most error messages
>>       --relative-to=FILE       print the resolved path relative to FILE
>>       --relative-base=FILE     print absolute paths unless paths below FILE
>>   -s, --strip                  don't expand symlinks
>>   -z, --zero                   separate output with NUL rather than newline
>>       --help     display this help and exit
>>       --version  output version information and exit
>> I was going to add a --readlink option to call readlink(3),
>> but that's a separate function really, and since readlink(1)
>> is widely available, I thought it better to not duplicate?
>> I was going to add a --common-prefix mode, to print
>> the common prefix of all supplied paths.
>> We can do this in future anyway.
>> Note this patch required this small update to gnulib:
> ...
>> Subject: [PATCH] readlink: A new program to print the resolved path
> s/readlink: A/realpath: a/

Oops I did that to avoid the commit hook rejecting the new prefix,
which is only catered for in the patch itself.
I forgot to do the final adjustment with `git commit --amend -n`.

> "make check" failed with this:
>   FAIL: misc/help-version (exit: 1)
>   =================================
>   ...
>   + args=
>   + env realpath
>   realpath: missing operand

That didn't fail for me?
Hmm realpath wasn't in my list of built_programs.
The reason is I had a test/.built-programs file present.
That should probably be updated unconditionally?
Anyway I now see the failure after first doing a `make clean`.

> -------------------------------------------------
> Reading "info realpath", I saw this:
>   `-s'
>   `--strip'
>        Do not resolve symbolic links.  Only resolve references to `/./',
>        `/../' and extra `/' characters.
> How about inserting "remove"?
>        Do not resolve symbolic links.  Only resolve references to `/./',
>        `/../' and remove extra `/' characters.


> Also, if it's (as I assume) a text-only operation, never stat'ing
> a named file, then say that:
>   Unlike other modes of operation, with this one, realpath operates
>   only on the file name, and does not touch any actual file.

No it honors -e and -m etc, so gnulib::canonicalize_filename_mode() does stat.
Hmm, I suppose the stat could be avoided with -ms (CAN_MISSING|CAN_NOLINKS).
I'll adjust gnulib accordingly, and add the above text conditional
on @option{-m}

> Reading only the documentation for --relative-base=FILE,
> I am not sure how it works:
> `--relative-base=FILE'
>      Ensure both the `--relative-to' and processed files are
>      subdirectories of FILE, or otherwise output the absolute file name.
>      Note this option honors the `-m' and `-e' options pertaining to
>      file existence.
> An example or two would help a lot.

I'll add something along these lines:

$ realpath --relative-to=/usr /tmp /usr/bin

$ realpath --relative-base=/usr --relative-to=/usr /tmp /usr/bin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]