I installed some software and I think afterwards I was navigating through CLI and noticed that some directories or some files in some directories had single quotation marks around the names. They don’t appear in the GUI. How do I get rid of them? Do I have to use a recursive command to delete the quotation marks for the entire file system?
I’ve actually had this problem a few times in the past but cannot recall why they happen nor what the solution was.
If you are referring to seeing filenames with spaces wrapped in single quotes when you do an “ls” then refer to this stackexchange answer for a discussion on the long history of why everyone considers this a major bug but the maintainers refuse to fix it. The short answer is to do “ls -N” to correct this problem, and you will probably want to create an alias to do this automatically for you.
It’s really neither a bug nor a problem. It is very reasonable default behavior to enable piping to or parsing by other commands because space is the default separator for arguments.
So you’re saying you do not already take the reasonable approach of quoting filenames in your scripts, and the rest of us have to work around your lack of foresight?
Feel free to travel back in time and have a discussion with Ken Thompson in ~1970, whether spaces in file/folder names should be allowed in the first place. I for one use an underscore instead, whenever I have control.
Yeah I try to avoid them as well, but sometimes you have filesystems shared by Windows users who don’t know any better. I also process tv show and movie files which always contains spaces in their names, so I just got in the habit of quoting the filenames so there’s never any question. One of these days I need to see if those single quotes interfere with the process of renaming files – do they get pulled in when you read a directory into an array? If so, then when I work with the filenames as strings it would mean that the new filename is incorrect. If they don’t get included, then the whole argument of it making it ‘easier’ to work from the command line is false because now you have inconsistent results depending on how exactly you work with the results from the ls command. As it is, I’ll probably have to start including the -N parameter in my scripts just to make sure I always get a known result now and in the future.
It’s certainly no bad habit to handle spaces in scripts preemptively, and obviously they do occur in the wild. Quotes from ls output do not get piped to other commands. I had to look that up myself right now, because it has been quite a while since it mattered to me.
$ touch 'file with spaces in name' $ ls 'file with spaces in name' $ ls | cat file with spaces in name $Looking through some scripts I wrote back in the day, I seem to like to use
ls -1in scripts. I guess that reduces ambiguity on what the separator is.Using ls -1 certainly helps if you are stripping content from the screen, but in recent years I have always found that using ls within a bash script (like if you use FILES=$((ls)) to get an array) returns a proper list correctly separated. It would not surprise me though if that is a feature of bash 4, I do remember we used to have to use the read command to get the appropriate output. So yeah, if all bash commands were simultaneously updated to strip those single quotes at the same time that it was added to the output of ls then it’s probably not an issue. I still find it a completely useless annoyance just seeing them in the output and having to add flags to all of my desktops and servers to strip out content that I never asked for. If somebody wanted this then why not let them add a flag to their machines to include the feature?
It’s definitely not a bug 😆
My experience is you should try to always use find over ls when writing robust scripts, and consider ls as just an end user tool, not a scripting tool.
deleted by creator