Help!! Filenames with blanks in them

[Bogomips]

But it's not about creating the folder, it's about finding it.

Nice one. Instead of counting sheep, fell asleep trying to solve problem of making directory with spaces, as well as directory path including directory with spaces.

[Rava]

But it's not about creating the folder, it's about finding it.

Nice one. Instead of counting sheep, fell asleep trying to solve problem of making directory with spaces, as well as directory path including directory with spaces.

Really funny stuff can happen when you are very very tired, In German we call that "schlaftrunken", you could translate into "drunk on sleeplessness" or "drugged with sleep", and it indeed is similar to drug overdoes, minus all the negative issues of drugs, you only have a weird experience and body & should not need to suffer...


Unless you drive a car or start working in Chernobyl at 0:01 a.m. Then bodily harm is part of a way darker journey into drunk on sleeplessness land.
(Me thinks the German phrase is the more lyrical one)
___________________

http://www.duden.de/rechtschreibung/schlaftrunken
http://www.dict.cc/?s=schlaftrunken

[brokenman]

Code: Select all

mkdir -p /tmp/play/"path with"/spaces
touch /tmp/play/path\ with/spaces/file.txt
find /tmp/play -name "file*" | xargs -n1 -i rm {}

[Bogomips]

^ Such a precise answer, that haven't a clue which issue is being addressed.

[Rava]

Code: Select all

mkdir -p /tmp/play/"path with"/spaces
touch /tmp/play/path\ with/spaces/file.txt
find /tmp/play -name "file*" | xargs -n1 -i rm {}

Indeed that works, usually lazy me just fires up mc instead, that one is usually able to remove even the weirdest of files. Like a file or folder called "*" (without the ", or with the "), or files with Carriage return in them, many scripts file name handling fail due to assuming a line they find is always a file name, never thinking of the possibility that a filename can contain more than one line.

And all such names are valid UNIX file names that can derail badly written scripts or programs.


There is only one character that cannot be part of any file name or folder: The Null Character, due to C being the core of UNIX and Linux, history wise and the Null character being a divider of data entities for C.

When one wants a failsafe way in handling filenames, use a way to have them separated by only NULL and not assume anything else what characters they can or cannot have.

___________________________________________

^ Such a precise answer, that haven't a clue which issue is being addressed.

We did encounter creating weird file names, but only as a by product. But @all, please look at this post where I praise donald for finally finding a solution and that at times are less complex, less formal approach is the better one: http://forum.porteus.org/viewtopic.php? ... 698#p44267

...

I also will include a new part of that script, cause usually I create the folder in /tmp by the naming convention and then xzm2dir the last working version of the settings module into that (to have all older settings and data in it), and then I would run the script to be in the right folders for only copy files that need or should be saved and leave out all others I want to discard.

But at times it happens I want to copy new content into the target folder, but forgot that I have so far not yet created the target folder, and also not yet did the xzm2dir into that very folder, so the mc still starts even when one of the panels could not open in the intended path since that path in non existent.


Instead of still starting mc with invalid folder my script should instead check if the "wildcard and spaces" path is a valid path, as in: run
# file "wildcard and spaces"
and look if we get as result ": directory" at the end as we need to get, since only then mc can be launched in the way it is intended...
(Or check if both paths are valid)

[Bogomips]

You can boil it down to this:

I want to call mc (via a script) with 2 paths. So that mc opens these "target path" in its left and right working panel, one is the source directory for backup copy, the other the target. The target directory in /tmp varies since I give it a name including version and date so that I can have several versions next to each other.


Both have whitespace. One also has a wildcard. (The one in /tmp)

The path with only whitespace you can enclose in " ". (In my example, the one in /home/rava, but could be anywhere with a needed path with whitespace)

The other one, you cannot use " " to protect the whitespaces, or else the wildcard * won't expand.

Code: Select all

# file /tmp/999-local-settings-3.1.*/home/rava/.moonchild\ productions/pale\ moon

That's an how it forks fine in bash itself, but not in a bash script. When you created a matching folder, e.g.

Code: Select all

# mkdir -p "/tmp/999-local-settings-3.1.0_2016-04-17/home/rava/.moonchild productions/pale moon"

the above would match, like I demonstrated with bash in my above post.


But when you try the same in a bash script, it fails. You get an "file or folder not found", or such error.

Like I said above, using " " won't work, since the * won't expand.
Using "\ " (minus the " ) also not works, the bash script complains about "path not found", even when the same works fine in bash itself....


That's boiled down to the basics. Well, at least I found a 2 part work around as quoted above, but I would prefer a solution in being able to give such wildcard and whitespace folder or filename and the script is able to expand the wildcard(s) while still respecting the whitespaces.

There is no mention here that the final aim is to delete the file.

[Rava]

There is no mention here that the final aim is to delete the file.

Please don't make a overly long or full quote for no reason. Please link to the article itself like so

_________________________

I looked through the whole post of yours http://forum.porteus.org/viewtopic.php? ... 698#p44192 but did not find *searchterm*
_________________________

That is much more readers friendly. The one who wants to check your claim can do so by clicking the link, all others have a much better readable article and can just carry on.

Thanks.

And yes, it is not mentioned in that post.