Hi,
I have submitted the patch long time ago as I was asked to add the
patch. However, nobody really takes a look at it. I feel really sad.
Could anybody take a look and see if it is above the quality criterion
and let me know what I need to change so this small utility can be
added to the reposit
On 11/30/2011 06:43 PM, Peng Yu wrote:
> Hi,
>
> I have submitted the patch long time ago as I was asked to add the
> patch. However, nobody really takes a look at it. I feel really sad.
> Could anybody take a look and see if it is above the quality criterion
> and let me know what I need to chang
Peng Yu wrote:
> I have submitted the patch long time ago as I was asked to add the
> patch. However, nobody really takes a look at it. I feel really sad.
> Could anybody take a look and see if it is above the quality criterion
> and let me know what I need to change so this small utility can be
>
On Thu, Dec 01, 2011 at 12:07:00PM +0100, Jim Meyering wrote:
> Peng Yu wrote:
> > I have submitted the patch long time ago as I was asked to add the
> > patch. However, nobody really takes a look at it. I feel really sad.
> > Could anybody take a look and see if it is above the quality criterion
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/01/2011 12:10 PM, Dmitry V. Levin wrote:
> On Thu, Dec 01, 2011 at 12:07:00PM +0100, Jim Meyering wrote:
>> Peng Yu wrote:
>>> I have submitted the patch long time ago as I was asked to add the patch.
>>> However, nobody really takes a look at i
On Thu, Dec 01, 2011 at 12:21:03PM +, Pádraig Brady wrote:
> On 12/01/2011 12:10 PM, Dmitry V. Levin wrote:
> > On Thu, Dec 01, 2011 at 12:07:00PM +0100, Jim Meyering wrote:
[...]
> >> Pádraig Brady and I talked about this today, and he suggested to call this
> >> new program realpath, and wit
> realpath [-s|--strip] [-z|--zero] filename ...
I'm not sure why you and Jim want to merge a different function under
the name realpath. To me, I think this less intuitive. The English
word 'real path' is different from the word 'relative path'. If
'relpath' is used, probably don't need to read
On 12/01/2011 03:26 PM, Peng Yu wrote:
>> realpath [-s|--strip] [-z|--zero] filename ...
>
> I'm not sure why you and Jim want to merge a different function under
> the name realpath. To me, I think this less intuitive. The English
> word 'real path' is different from the word 'relative path'. I
> Given there are existing realpath utils in both BSD and Debian,
It is not necessarily everybody knows realpath. By default ubuntu
doesn't have realpath installed. I'm not sure we should make the name
less obvious than it should be just because there is a different that
happen share some commonal
On 12/01/2011 10:18 AM, Peng Yu wrote:
>> Given there are existing realpath utils in both BSD and Debian,
>
> It is not necessarily everybody knows realpath. By default ubuntu
> doesn't have realpath installed. I'm not sure we should make the name
> less obvious than it should be just because ther
On 12/01/2011 10:24 AM, Eric Blake wrote:
> On 12/01/2011 10:18 AM, Peng Yu wrote:
>>> Given there are existing realpath utils in both BSD and Debian,
>>
>> It is not necessarily everybody knows realpath. By default ubuntu
>> doesn't have realpath installed.
And if coreutils adds a realpath, then
Hi Jim,
> realpath --relative-start=DIR FILE ...
I had some private email conversation with Eric. Per Eric's
suggestion, it is better to document it to the mailing list for future
reference and to make my point clearer.
Just that there is a 3rd party command realpath (which doesn't have
the r
On 12/01/2011 03:00 PM, Peng Yu wrote:
>
>> but few people know that hidden within readlink they will find a
>> file-name canonicalization tool
>
> The reason is "readlink" is not a good name for canonicalization.
That's true; we've had a number of people wonder why coreutils doesn't
have 'real
On Thu, Dec 01, 2011 at 03:18:09PM -0700, Eric Blake wrote:
> On 12/01/2011 03:00 PM, Peng Yu wrote:
> >
> >> but few people know that hidden within readlink they will find a
> >> file-name canonicalization tool
>
> > The reason is "readlink" is not a good name for canonicalization.
>
> That's t
On Fri, Dec 02, 2011 at 03:25:45AM +0400, Dmitry V. Levin wrote:
> On Thu, Dec 01, 2011 at 03:18:09PM -0700, Eric Blake wrote:
> > On 12/01/2011 03:00 PM, Peng Yu wrote:
> > >
> > >> but few people know that hidden within readlink they will find a
> > >> file-name canonicalization tool
> >
> > >
On 12/02/2011 01:21 AM, Guillaume Kielwasser wrote:
> and what about something like:
>
> getpath -C|--canon// simulate realpath
> getpath -R|--relative // simulate relpath
> getpath -L|--link // simulate readlink
A good suggestion, thanks.
It's the right level of functionalit
Pádraig Brady wrote:
> On 12/02/2011 01:21 AM, Guillaume Kielwasser wrote:
> > and what about something like:
> >
> > getpath -C|--canon// simulate realpath
> > getpath -R|--relative // simulate relpath
> > getpath -L|--link // simulate readlink
>
> A good suggestion, thanks.
Peng Yu wrote:
> Hi Jim,
>
>> realpath --relative-start=DIR FILE ...
>
> I had some private email conversation with Eric. Per Eric's
> suggestion, it is better to document it to the mailing list for future
> reference and to make my point clearer.
Keeping discussion on the mailing list is almos
On Fri, Dec 02, 2011 at 10:30:17AM +0100, Voelker, Bernhard wrote:
> Pádraig Brady wrote:
> > On 12/02/2011 01:21 AM, Guillaume Kielwasser wrote:
> > > and what about something like:
> > >
> > > getpath -C|--canon// simulate realpath
> > > getpath -R|--relative // simulate relpath
> >
On 12/02/2011 09:30 AM, Voelker, Bernhard wrote:
> Pádraig Brady wrote:
>> On 12/02/2011 01:21 AM, Guillaume Kielwasser wrote:
>>> and what about something like:
>>>
>>> getpath -C|--canon// simulate realpath
>>> getpath -R|--relative // simulate relpath
>>> getpath -L|--link //
2011/12/2 Pádraig Brady :
> On 12/02/2011 09:30 AM, Voelker, Bernhard wrote:
>> Pádraig Brady wrote:
>>> On 12/02/2011 01:21 AM, Guillaume Kielwasser wrote:
and what about something like:
getpath -C|--canon // simulate realpath
getpath -R|--relative // simulate relpat
On 12/02/2011 12:52 PM, Sami Kerola wrote:
> 2011/12/2 Pádraig Brady :
>> On 12/02/2011 09:30 AM, Voelker, Bernhard wrote:
>>> Pádraig Brady wrote:
On 12/02/2011 01:21 AM, Guillaume Kielwasser wrote:
> and what about something like:
>
> getpath -C|--canon// simulate realpat
On 12/02/2011 01:03 PM, Pádraig Brady wrote:
> On 12/02/2011 12:52 PM, Sami Kerola wrote:
>> 2011/12/2 Pádraig Brady :
>>> On 12/02/2011 09:30 AM, Voelker, Bernhard wrote:
Pádraig Brady wrote:
> On 12/02/2011 01:21 AM, Guillaume Kielwasser wrote:
>> and what about something like:
>
On Fri, Dec 02, 2011 at 01:13:21PM +, Pádraig Brady wrote:
> On 12/02/2011 01:03 PM, Pádraig Brady wrote:
> > On 12/02/2011 12:52 PM, Sami Kerola wrote:
> >> 2011/12/2 Pádraig Brady :
> >>> On 12/02/2011 09:30 AM, Voelker, Bernhard wrote:
> Pádraig Brady wrote:
> > On 12/02/2011 01:21
Hi,
On Thu, Dec 01, 2011 at 03:18:09PM -0700, Eric Blake wrote:
> On 12/01/2011 03:00 PM, Peng Yu wrote:
> >
> >> but few people know that hidden within readlink they will find a
> >> file-name canonicalization tool
> >
> > The reason is "readlink" is not a good name for canonicalization.
>
> M
On 12/02/2011 02:45 AM, Jim Meyering wrote:
> Just because others use a name doesn't make it good.
>
> IMHO, "relpath" is not a very good name.
> One minor issue is with the word "path" in "relpath".
> "PATH" is often used to mean a shell's search "path" (list of directories).
> "file name" is the
OK lets decide first if we're going with a single or separate commands.
There seems to be an even split on that preference,
which I think can be summarised as these two options:
1. relpath¹; realpath; readlink
2. realpath² --relative --canon --link
cheers,
Pádraig.
¹ Other names suggested:
On 12/05/2011 10:32 AM, Pádraig Brady wrote:
> OK lets decide first if we're going with a single or separate commands.
> There seems to be an even split on that preference,
> which I think can be summarised as these two options:
>
> 1. relpath¹; realpath; readlink
>
> 2. realpath² --relative
Pádraig Brady wrote:
> OK lets decide first if we're going with a single or separate commands.
> There seems to be an even split on that preference,
> which I think can be summarised as these two options:
>
> 1. relpath¹; realpath; readlink
>
> 2. realpath² --relative --canon --link
>
> chee
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.
cheers,
Pádraig.
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 functio
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 in
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 in
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 t
Pádraig Brady wrote:
...
>>> 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 c
Pádraig Brady wrote:
...
>> 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 t
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 in
On 12/31/2011 11:27 AM, Jim Meyering wrote:
> Pádraig Brady wrote:
> ...
>>> 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 o
Pádraig Brady wrote:
> On 12/31/2011 11:27 AM, Jim Meyering wrote:
>> Pádraig Brady wrote:
>> ...
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
> `--relative-base=BASE'
> Only output relative names when both the `--relative-to' and processed
> FILEs are descendants of BASE. Otherwise output the absolute file name.
> Note this option honors the @option{-m} and @option{-e} options
> pertaining to file existence.
'--relative
On 05/13/2012 04:27 AM, Peng Yu wrote:
>> `--relative-base=BASE'
>> Only output relative names when both the `--relative-to' and processed
>> FILEs are descendants of BASE. Otherwise output the absolute file name.
>> Note this option honors the @option{-m} and @option{-e} options
>>
Pádraig Brady wrote:
> On 05/13/2012 04:27 AM, Peng Yu wrote:
>>> `--relative-base=BASE'
>>> Only output relative names when both the `--relative-to' and processed
>>> FILEs are descendants of BASE. Otherwise output the absolute file name.
>>> Note this option honors the @option{-m} a
On Mon, May 14, 2012 at 3:33 AM, Pádraig Brady wrote:
> On 05/13/2012 04:27 AM, Peng Yu wrote:
>>> `--relative-base=BASE'
>>> Only output relative names when both the `--relative-to' and processed
>>> FILEs are descendants of BASE. Otherwise output the absolute file name.
>>> Note thi
On 05/14/2012 01:39 PM, Peng Yu wrote:
> On Mon, May 14, 2012 at 3:33 AM, Pádraig Brady wrote:
>> On 05/13/2012 04:27 AM, Peng Yu wrote:
`--relative-base=BASE'
Only output relative names when both the `--relative-to' and processed
FILEs are descendants of BASE. Otherwise ou
44 matches
Mail list logo
