Description of problem: The conversion is non usual, even if easy to find and replace, but not so easy for beginners. This scheme seems not good for all file access interfaces. (file name or directory is not visible) Version-Release number of selected component (if applicable): Actual RC How reproducible: 1. Test these 'bad' names: ~/'Repertoires effacés'/ 'Fichier château'.pdf 2. Your new Simple Scan application, uses a default Save file name like "Document éssayée" ---> the Save process is blocked with 3 notifications of bad filename until you cleared it .... booooof ! Question: Is it a new idea/design ? P.S. Installation from iso and the rest of Mageia-6 was perfect for me !! ready for release (if "5 -> 6" upgrade sequence is OK ...!) Thanks for coop and all your best work. Serge Montagnac. I develop on Mageia and install it from the beginning (of Mandrake). I evangelize since 25 years (linux 0.97) -- go, go Mageia! --
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) => NEEDINFOCC: (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.
Component: Release (media or process) => RPM PackagesKeywords: NEEDINFO => (none)CC: sysadmin-bugs => basesystemAssignee: bugsquad => pkg-bugsSource RPM: (none) => simple-scan
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.
Source RPM: simple-scan => core-utils, simple-scanSummary: directories and/or file names containing space or accents converted in 'Répertoires abonnés' ... => why-is-ls-suddenly-wrapping-items-with-spaces-in-single-quotesTarget Milestone: --- => Mageia 6
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?