Re: broken ls in coreutils 8.25

[Pádraig Brady]

On 02/02/16 21:44, Harald Dunkel wrote:
> On 02/02/16 14:30, Eric Blake wrote:
>> On 02/01/2016 11:17 PM, Harald Dunkel wrote:
>>>
>>> This means that the user has to count '\' and "'" in the output of ls to 
>>> get the "real" filename.
> 
>> Yeah, but which are you more likely to do, retype the "real" filename 
>> manually (and insert your own shell quoting as appropriate), or 
>> copy-and-paste the existing output with a mouse click or two?
> 
> 
> Talking about copy and paste: Have you tried to copy and paste
> a string like
> 
>       'mom'\''s pictures.png'
> or
>       mom'\''s pictures.png
> 
> into the file selection box of your favorite gui application?
> How likely is that this gui knows how to handle the "'" and
> the "\'" correctly?
> 
> How are you going to explain a noob that he has to edit the
> pasted string to
> 
>       mom's pictures.png
> 
> to make it work?

Yes this is a functional disadvantage worth mentioning,
though I'm still not convinced it will impact many.
Personally I rarely if ever paste from shell to gui since
one doesn't normally have the gui app in the right dir,
and if you do it's usually easier to select the file
from the file dialog you'd be opening anyway.

Generally how I would interact with a gui app from shell is:

xdg-open .
xdg-open 'pasted name'
gui-app  'pasted name'
realpath 'pasted name'  # Paste output of this to gui app (gives dir)

Again if your edge case usage doesn't fit the above,
then you can just add -N to your ls alias
(noting that will fail in this use case also for
 chars that are then represented with ?)

cheers,
Pádraig.