I installed the following in an attempt to address the issues brought
up in this thread, along with some other problems I noticed when
comparing GNU ln's to FreeBSD ln's behavior.
2005-11-16 Paul Eggert [EMAIL PROTECTED]
* NEWS: Improve quality of ln's diagnostics.
*
On Friday 28 October 2005 08:07, Bob Proulx wrote:
Elan Ruusamäe wrote:
commands used to compose this email:
$ LC_ALL=et_EE ln -s /inexistent1/path1 /inexistent2/path2
$ LC_ALL=C ln -s /inexistent1/path1 /inexistent2/path2
...
suggested change:
...
or remove the symlink destination
Elan Ruusamäe [EMAIL PROTECTED] writes:
also in this topic, 'ln -v' outputs confusing message:
$ ln test/jobs/*1.3.34* -v .
create hard link `./htpasswd-apache1-1.3.34-3.1.i686.rpm' to
`test/jobs/htpasswd-apache1-1.3.34-3.1.i686.rpm'
Perhaps create should be changed to add.
Andreas.
--
[EMAIL PROTECTED] (Bob Proulx) writes:
Is this on a development branch? Or just something to remember to
put in the main trunk once things are allowed to be a little
unstable again?
The latter, at least for now.
___
Bug-coreutils mailing list
Paul Eggert wrote:
How about this patch? I think it addresses all issues raised so far
on this thread.
+ ? (errno != ENAMETOOLONG *source
+ ? _(creating symbolic link %s)
+ : _(creating symbolic link %s to %s))
With that patch applied I now have this output:
[EMAIL PROTECTED] (Bob Proulx) writes:
But the hard link case is much more complicated than before. And
unfortunately does not cover the main case.
I'm afraid it's the best we can do for ENOENT without issuing more
system calls. If link(a,b) fails with ENOENT, it could be a problem
with
Paul Eggert wrote:
Bob Proulx writes:
But the hard link case is much more complicated than before. And
unfortunately does not cover the main case.
I'm afraid it's the best we can do for ENOENT without issuing more
system calls. If link(a,b) fails with ENOENT, it could be a problem
with
[EMAIL PROTECTED] (Bob Proulx) writes:
I like this suggestion of yours. I agree that the symlink value
cannot be a source of error.
It can, when it is too long.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key
Andreas Schwab wrote:
Bob Proulx writes:
I like this suggestion of yours. I agree that the symlink value
cannot be a source of error.
It can, when it is too long.
Yes, you are correct. The limit is 3976 characters on my system with
a reiserfs filesystem. I ran the following script to
How about this patch? I think it addresses all issues raised so far
on this thread.
2005-10-28 Paul Eggert [EMAIL PROTECTED]
* src/ln.c (do_link): In diagnostics, don't mention operands when
we know they did not contribute to the error.
--- src/ln.c.~1.153.~ 2005-10-28
Elan Ruusamäe wrote:
commands used to compose this email:
$ LC_ALL=et_EE ln -s /inexistent1/path1 /inexistent2/path2
$ LC_ALL=C ln -s /inexistent1/path1 /inexistent2/path2
...
suggested change:
...
or remove the symlink destination from error message:
ln: creating symbolic link
11 matches
Mail list logo
