Bug 21190

Thanks Serge :-)
(I started later, with Mandrake 8.1)

To my surprise, the default file manager in XFCE doesn't have a problem with directory and file names with a space in them.

I understand this bug report is about simple-scan using a default file name with a space in the name, and then failing to save the file because of that space. Is that correct?

If so: I cannot reproduce that, in my language the default file name is:

      Gescand document.pdf

But it is saved like that without any problems, and Atril document viewer has no problem opening it.

I don't understand the summary of this bug report "directories and/or file names containing space or accents converted in 'Répertoires abonnés' ..." :-(

Keywords: (none) => NEEDINFO
CC: (none) => marja11

>> I don't understand the summary of this bug report "directories and/or file names containing space or accents converted in 'Répertoires abonnés' ..." :-(

I mean that these directory names and file names containing accents and/or spaces, appeared previously (mga5) "as it is" when listed in a console or an xterm, and after upgrading to mga6, they are all listed between single quotes ...
... so, I worry about this behavior, is it a new feature ??

Normally, in bash we had to protect by a  \ all spaces and abnormal characters to be able to autocomplete these filenames ...

(In reply to Serge Montagnac from comment #2)

> 
> I mean that these directory names and file names containing accents and/or
> spaces, appeared previously (mga5) "as it is" when listed in a console or an
> xterm, and after upgrading to mga6, they are all listed between single
> quotes ...
> ... so, I worry about this behavior, is it a new feature ??
> 
> Normally, in bash we had to protect by a  \ all spaces and abnormal
> characters to be able to autocomplete these filenames ...

I did:

 touch 'test file'
 chmod 777 t<tab> (that completed to "chmod 777 test\ file")
 ./t<tab> (that completed to "./test\ file")
 ls | grep test (that resulted in "test file*"
 rm t<tab> (that completed to "rm test\ file"

So there seems to be no problem.

The error simple-scan throws for you, might be unrelated. The default simple-scan file name that you got, "Document éssayée", translates to "Document tried", but the default simple-scan file name that I got was "Gescand document.pdf" which translates to "Scanned document.pdf"

Assigning to all packagers collectively, because simple-scan does not have a registered maintainer. CC'ing the base system maintainers in case I'm totally wrong and your problem is caused by the change in how file and directory names with spaces or funny characters are shown in cli and tty, after all. 

Please, dear maintainers, reassign if I assigned wrongly.

Leaving the summary unchanged for now.

Keywords: NEEDINFO => (none)
Assignee: bugsquad => pkg-bugs
Source RPM: (none) => simple-scan
Component: Release (media or process) => RPM Packages
CC: sysadmin-bugs => basesystem

I'll check tomorrow on the distant machine, to be more accurate.

The look I talk about is 'test file'.pdf   

so, you must type 
$ touch "'test file'.pdf"
to simulate the result. 

Concerning simple-scan you are right about the translation problem from
"Scanned document".pdf to "document scanné" in French ...BUT, the accent
in the second word triggers 3 "file name errors" notifications ...:-(

[rene@blackbox Vidéos]$ ls
A400M.odp
AIRBUS_A400_M-tiss.pps
'CEUX DE 14-18.pdf'
'Entrainement Mission Rafale Nucléaire.eml'
'Fwd: HELL for HONSHU: B-29 Strategic Bombing of Japan (720p).eml'
Las_4_estaciones_de_Vivaldi_1.pps
La_Toscane__R_.pps
'Le Night-Hawk a pris sa retraite.odp'
'Leslibraires.fr - Récupération du mot de passe.eml'
lions.wmv
'LIVE-BOX_infos .pdf'
Machine_pour_voir_dans_le_futur____1.pps
magnifique.pps
Marc_Herman._._.wmv
message.eml
Mirage_IV.odp
'Montage complet d'\''un V12 !.eml'
Monture_2010-05-16.pps
MosquitoManufacturing-1944.wmv
Nellis_air_show_2008.pps
'Partie 1.2'
'Partie 1.3'

This is the look of ls in Konsole !

I finally found the problem ... a bunch of guys had an idea ;-) to lost our time !

If you type 'ls -N' filenames looks normal. (we have to change it in alias...)
 
That feature should be optional, not the default.
 
https://unix.stackexchange.com/questions/258679/why-is-ls-suddenly-wrapping-items-with-spaces-in-single-quotes

another advice :
my apologies - apparently you are safely shell-quoting the shell-quotes at least. i still do not like it. the options are fine - but altering the very well-specified default behavior of a decades-old unix core utility in such a way that diminishes its veracity can only be a bad idea.

I let you close the case. RESOLVED ?
Serge.

Suggestion to avoid any side-effects with sed. lex or awk:

    "ls -N" should be the default behavior of unaliased "ls"
Serge Montagnac.

(In reply to Serge Montagnac from comment #7)
> Suggestion to avoid any side-effects with sed. lex or awk:
> 
>     "ls -N" should be the default behavior of unaliased "ls"
> Serge Montagnac.

I disagree : script writers should always evolve their scripts according to new releases of tools. Furthermore, we should not change the new upstream default, as it makes users feel it was not updated. I suggest you write this new behaviour in the release notes, indicating the alias that brings back the old behaviour.

CC: (none) => lists.jjorge

"ite misa est" ;-(
Serge.

Yeah, I hit this "bug" as well a week or so ago -- within minutes after booting into MGA6 for the first time -- but only ran across this report today.  I chose to resolve the irritation introduced with this "improvement" by adding the following to my /usr/local/etc/bashrc file:

    export QUOTING_STYLE=literal


This report should probably be marked NOTABUG or some such, but what a ridiculously annoying change.  It seems to me, more often than not, that the Good Idea Fairy deserves a good smack from a fly swatter.

And while I'm griping, has anyone else noticed how VIM no longer creates backup~ files out of the box?  To restore its old, sane, behaviour I had to adjust my ~/.vimrc with:

    set backup


Bloody annoying...

CC: (none) => johnltw

From what I've read around (it's not specified in the documentation of ls though), the quotes for filenames with spaces are only added when printing to a terminal, therefore scripts which pipe to other programs like sed or awk shouldn't break

CC: (none) => ita84

(In reply to Davide Nifosi from comment #11)
> From what I've read around (it's not specified in the documentation of ls
> though), the quotes for filenames with spaces are only added when printing
> to a terminal, therefore scripts which pipe to other programs like sed or
> awk shouldn't break
That was my impression as well: that the quotes were merely cosmetic to terminal output (almost as if ls -Q hd been set to default, but with single quotes instead).  I got rid of them at first sight simply because they were annoying me and never got around to discovering if they broke my scripts.  I can't see how they could if they're just cosmetic though.  Perhaps they become true quotes when redirected?

As this bugreport was filed against MGA6 which is EOL since Sep 2019, is this still a problem with MGA8?

Since there was no update from reporter since 2017 can we consider this bug as OLD?

Status: NEW => NEEDINFO

(In reply to sturmvogel from comment #13)
> As this bugreport was filed against MGA6 which is EOL since Sep 2019, is
> this still a problem with MGA8?
> 
> Since there was no update from reporter since 2017 can we consider this bug
> as OLD?

It should have been closed ages ago, because it isn't a bug, but an upstream decision that caused ls to behave differently https://lists.gnu.org/archive/html/coreutils/2016-02/msg00000.html


Closing as INVALID because, unfortunately, we don't have the option to close as NOTABUG

Status: NEEDINFO => RESOLVED
Resolution: (none) => INVALID