GNU bug report logs - #17618
ls -l dangerous when listing links

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17618 in the body.
You can then email your comments to 17618 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michał Adamczyk <szemkel <at> owce.org>
To: bug-coreutils <at> gnu.org
Subject: ls -l dangerous when listing links
Date: Wed, 28 May 2014 15:36:09 +0200

Call it a bug or call it a feature. It is dangerous though.

When using `ls -l` to list a directory with links in it, it will produce 
an output similar to this:

lrwxrwxrwx 1 user group 30 1980-01-01 00:01 link_name -> 
/path/to/destination/file

Pretty cool, huh?
However, if you select this line and accidentally hit right mouse 
button, it'll get copied to your prompt. And if you select more than one 
line, it'll get copied with \n which will get interpreted as if you 
pushed the Enter.

So the whole line gets interpreted as a command:
lrwxrwxrwx [no such command] 1 user group 30 1980-01-01 00:01 link_name 
- [parameters for non-existing command] > /path/to/destination/file 
[redirect output to that file]

Since the output is empty, you'll get the target of that link 
overwritten with an empty file.

My suggestion is to change the representation symbols of link to 
something that won't get interpreted.


Cheers,

Mike

Message #8 received at 17618 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Michał Adamczyk <szemkel <at> owce.org>
Cc: 17618 <at> debbugs.gnu.org
Subject: Re: bug#17618: ls -l dangerous when listing links
Date: Wed, 28 May 2014 16:41:52 +0100

tag 17618 notabug
close 17618
stop

On 05/28/2014 02:36 PM, Michał Adamczyk wrote:
> Call it a bug or call it a feature. It is dangerous though.
> 
> When using `ls -l` to list a directory with links in it, it will produce an output similar to this:
> 
> lrwxrwxrwx 1 user group 30 1980-01-01 00:01 link_name -> /path/to/destination/file
> 
> Pretty cool, huh?
> However, if you select this line and accidentally hit right mouse button, it'll get copied to your prompt. And if you select more than one line, it'll get copied with \n which will get interpreted as if you pushed the Enter.
> 
> So the whole line gets interpreted as a command:
> lrwxrwxrwx [no such command] 1 user group 30 1980-01-01 00:01 link_name - [parameters for non-existing command] > /path/to/destination/file [redirect output to that file]
> 
> Since the output is empty, you'll get the target of that link overwritten with an empty file.
> 
> My suggestion is to change the representation symbols of link to something that won't get interpreted.

I see the issue.
Though I don't think there is anything we can do just to backwards compat.
I'm sure there are scripts somewhere depending on the '->' portion.
You're free to change that yourself though with a wrapper.
See http://www.pixelbeat.org/scripts/l for example which uses '▪▶' instead.

thanks,
Pádraig.

Message #15 received at 17618 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Michał Adamczyk <szemkel <at> owce.org>,
 17618 <at> debbugs.gnu.org
Subject: Re: bug#17618: ls -l dangerous when listing links
Date: Wed, 28 May 2014 09:46:10 -0600

[Message part 1 (text/plain, inline)]

tag 17618 wontfix
thanks

On 05/28/2014 07:36 AM, Michał Adamczyk wrote:
> Call it a bug or call it a feature. It is dangerous though.
> 
> When using `ls -l` to list a directory with links in it, it will produce
> an output similar to this:
> 
> lrwxrwxrwx 1 user group 30 1980-01-01 00:01 link_name ->
> /path/to/destination/file

> 
> Since the output is empty, you'll get the target of that link
> overwritten with an empty file.
> 
> My suggestion is to change the representation symbols of link to
> something that won't get interpreted.

The use of "->" is required by POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html

>> If the file is a symbolic link and the -L option is not specified, this information shall be about the link itself and the <pathname> field shall be of the form:
>> 
>> "%s -> %s", <pathname of link>, <contents of link>
>> 

So we can't change it unless we add a NEW option; but adding a new
option means that it won't be available by default.

There have been suggestions in the past about using a UTF-8 arrow, but
they have similarly been rejected.  Sorry.

I'm closing this report, because we can't do anything about it; but feel
free to add further comments.


-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at 17618 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Michał Adamczyk <szemkel <at> owce.org>,
 17618 <at> debbugs.gnu.org
Subject: Re: bug#17618: ls -l dangerous when listing links
Date: Wed, 28 May 2014 09:54:33 -0600

[Message part 1 (text/plain, inline)]

On 05/28/2014 09:46 AM, Eric Blake wrote:
> tag 17618 wontfix
> thanks
> 
> On 05/28/2014 07:36 AM, Michał Adamczyk wrote:
>> Call it a bug or call it a feature. It is dangerous though.
>>
>> When using `ls -l` to list a directory with links in it, it will produce
>> an output similar to this:
>>
>> lrwxrwxrwx 1 user group 30 1980-01-01 00:01 link_name ->
>> /path/to/destination/file
> 
>>
>> Since the output is empty, you'll get the target of that link
>> overwritten with an empty file.

One thing you CAN do is set the noclobber option of your shell.  POSIX
requires that 'set -C' cripple '>' redirection to an existing file
(scripts can force overwrites using '>|').  This would prevent the shell
from doing any overwriting to empty files if you accidentally paste ls
output, although it has the minor drawback that not all shell scripts
are robustly written to still work in the presence of set -C.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #23 received at 17618 <at> debbugs.gnu.org (full text, mbox):

From: Michał Adamczyk <szemkel <at> owce.org>
To: 17618 <at> debbugs.gnu.org
Subject: Oh, well...
Date: Wed, 28 May 2014 18:43:15 +0200

Thanks for your suggestions.
I'd say that the first thing for me to do about it is to actually pay 
attention when using mouse.
'set -C' is a decent idea, however I think the problem is dangerous only 
for folks that don't know about it.
I guess I'll just spread the word so that others wouldn't do the same 
silly mistake I did.
"It's a console, dammit. Leave the bloody mouse alone" ;)

Cheers,

Mike

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.