Hi,
How can I specify filenames with spaces in tmpfiles.d configuration files? There's no hint in `man tmfiles.d'. I tried
- fstab style: d /foo\040bar 0755 root root - web style: d /foo%20bar 0755 root root - quoted style 1: d "/foo bar" 0755 root root - quoted style 2: d '/foo bar' 0755 root root
This results in two directories
/foo\040bar /foo%20bar
and two error messages:
Path '"/foo' not absolute. Path ''/foo' not absolute.
So, do I have to take it that tmpfiles.d doesn't grok spaces in filenames at all?
Please note, I'm not asking for the obvious answer "don't do this" and I'm also not asking for the counter question "why do you need this?"
Corinna
On Jun 1 10:51, Patrick O'Callaghan wrote:
On Wed, 2011-06-01 at 17:11 +0200, Corinna Vinschen wrote:
- fstab style: d /foo\040bar 0755 root root
- web style: d /foo%20bar 0755 root root
- quoted style 1: d "/foo bar" 0755 root root
- quoted style 2: d '/foo bar' 0755 root root
Try:
/foo\ bar
Uh, I forgot to mention it in my list. I tried that first, actually, and this results in another error message:
d /foo\ bar 0755 root root
Invalid mode 'bar'.
Just a thought.
Thanks, Corinna
On 1 June 2011 16:11, Corinna Vinschen vinschen@redhat.com wrote:
Hi,
How can I specify filenames with spaces in tmpfiles.d configuration files? There's no hint in `man tmfiles.d'. I tried
- fstab style: d /foo\040bar 0755 root root
- web style: d /foo%20bar 0755 root root
- quoted style 1: d "/foo bar" 0755 root root
- quoted style 2: d '/foo bar' 0755 root root
This results in two directories
/foo\040bar /foo%20bar
and two error messages:
Path '"/foo' not absolute. Path ''/foo' not absolute.
So, do I have to take it that tmpfiles.d doesn't grok spaces in filenames at all?
Please note, I'm not asking for the obvious answer "don't do this" and I'm also not asking for the counter question "why do you need this?"
As usual both of these might push in the direction of another way to solve the problem. From checking the documentation it seems packages are expected to define patterns here for their tmpfiles which they should have control over. Which I guess is not the situation you're dealing with. Looking at it I think the short answer is you can't as tmpfiles.c is just using sscanf to parse this line: http://cgit.freedesktop.org/systemd/tree/src/tmpfiles.c Line 670: if (sscanf(buffer, "%c " "%ms " "%ms " "%ms " "%ms " "%ms", &i->type, &i->path, &mode, &user, &group, &age) < 2) { log_error("[%s:%u] Syntax error.", fname, line); r = -EIO; goto finish; }
So the long answer is you either have to modify tmpfiles.c to deal with this or write a similar daemon to do it.
On 06/01/11 09:37, Ian Malone wrote:
On 1 June 2011 16:11, Corinna Vinschenvinschen@redhat.com wrote:
Hi,
How can I specify filenames with spaces in tmpfiles.d configuration files? There's no hint in `man tmfiles.d'. I tried
- fstab style: d /foo\040bar 0755 root root
- web style: d /foo%20bar 0755 root root
- quoted style 1: d "/foo bar" 0755 root root
- quoted style 2: d '/foo bar' 0755 root root
This results in two directories
/foo\040bar /foo%20bar
and two error messages:
Path '"/foo' not absolute. Path ''/foo' not absolute.
So, do I have to take it that tmpfiles.d doesn't grok spaces in filenames at all?
Please note, I'm not asking for the obvious answer "don't do this" and I'm also not asking for the counter question "why do you need this?"
As usual both of these might push in the direction of another way to solve the problem. From checking the documentation it seems packages are expected to define patterns here for their tmpfiles which they should have control over. Which I guess is not the situation you're dealing with. Looking at it I think the short answer is you can't as tmpfiles.c is just using sscanf to parse this line: http://cgit.freedesktop.org/systemd/tree/src/tmpfiles.c Line 670: if (sscanf(buffer, "%c " "%ms " "%ms " "%ms " "%ms " "%ms", &i->type, &i->path, &mode, &user, &group, &age)< 2) { log_error("[%s:%u] Syntax error.", fname, line); r = -EIO; goto finish; }
So the long answer is you either have to modify tmpfiles.c to deal with this or write a similar daemon to do it.
Since a space is Unix's and Linux's chosen field separator, I think having a space in filenames should be avoided. there are many situations where spaces in filenames cause problems. A simple example:
for i in *; do [ -f $i ] && echo $i is a file done
you will see that the file with spaces in it's name will not be recognized as a file because each space-separated member of that file name becomes a separate argument when * is expanded by the shell. There are probably other more serious problems posed by spaces in filenames.
On Jun 1 09:59, JD wrote:
On 06/01/11 09:37, Ian Malone wrote:
On 1 June 2011 16:11, Corinna Vinschenvinschen@redhat.com wrote:
Hi,
How can I specify filenames with spaces in tmpfiles.d configuration files? There's no hint in `man tmfiles.d'. I tried
- fstab style: d /foo\040bar 0755 root root
[...] So, do I have to take it that tmpfiles.d doesn't grok spaces in filenames at all?
Please note, I'm not asking for the obvious answer "don't do this" and I'm also not asking for the counter question "why do you need this?"
[...] So the long answer is you either have to modify tmpfiles.c to deal with this or write a similar daemon to do it.
I guess this should be converted into a bugzilla entry then.
Since a space is Unix's and Linux's chosen field separator,
Just because the space is a field separator doesn't mean there are no ways to define spaces in filenames.
I think having a space in filenames should be avoided. there
That's not always possible and you can't ask all users to rename their files. Filenames like "Expenses May 2011.odt" are just to be expected. Another example is the default naming of CF or SD media formatted on certain camera models. Yet another exmaple are customer request.
are many situations where spaces in filenames cause problems. A simple example:
for i in *; do [ -f $i ] && echo $i is a file done
Which is just an example of insufficient quoting. If this isn't part of a script which exactly knows that no filename will have spaces, it's broken by design. Spaces in filenames are perfectly valid and system tools which may come into contact with user-defined content should be able to deal with them.
The fact that even /etc/fstab (rather, mount(8)) deals with spaces in mount points shows that there is a need and a way to handle them.
Having said that, using the space definition in /etc/fstab shouldn't be too hard to do in tmpfiles.d as well.
Corinna
On 1 June 2011 19:27, Corinna Vinschen vinschen@redhat.com wrote:
On Jun 1 09:59, JD wrote:
On 06/01/11 09:37, Ian Malone wrote:
On 1 June 2011 16:11, Corinna Vinschenvinschen@redhat.com wrote:
Hi,
How can I specify filenames with spaces in tmpfiles.d configuration files? There's no hint in `man tmfiles.d'. I tried
- fstab style: d /foo\040bar 0755 root root
[...] So, do I have to take it that tmpfiles.d doesn't grok spaces in filenames at all?
Please note, I'm not asking for the obvious answer "don't do this" and I'm also not asking for the counter question "why do you need this?"
[...] So the long answer is you either have to modify tmpfiles.c to deal with this or write a similar daemon to do it.
I guess this should be converted into a bugzilla entry then.
That's not always possible and you can't ask all users to rename their files. Filenames like "Expenses May 2011.odt" are just to be expected. Another example is the default naming of CF or SD media formatted on certain camera models. Yet another exmaple are customer request.
So far as I understand from the manpage, tmpfiles.d is not so much for cleaning the tmp directory on a regular basis as for creating and managing temporary files and directories on volatile filesystems. I'm not sure there's really a compelling argument for having this as a request for feature, except if you must have spaces in the temporary directory name for some reason. Being able to use anything you can put in fstab (consistency argument) is probably the only one that flies. If you have customers that run unix, care exactly what temporary system locations you use and insist there are spaces in the names then you have very weird customers.
On Jun 1 21:10, Ian Malone wrote:
On 1 June 2011 19:27, Corinna Vinschen vinschen@redhat.com wrote:
On Jun 1 09:59, JD wrote:
On 06/01/11 09:37, Ian Malone wrote:
On 1 June 2011 16:11, Corinna Vinschenvinschen@redhat.com wrote:
Hi,
How can I specify filenames with spaces in tmpfiles.d configuration files? There's no hint in `man tmfiles.d'. I tried
- fstab style: d /foo\040bar 0755 root root
[...] So, do I have to take it that tmpfiles.d doesn't grok spaces in filenames at all?
Please note, I'm not asking for the obvious answer "don't do this" and I'm also not asking for the counter question "why do you need this?"
[...] So the long answer is you either have to modify tmpfiles.c to deal with this or write a similar daemon to do it.
I guess this should be converted into a bugzilla entry then.
That's not always possible and you can't ask all users to rename their files. Filenames like "Expenses May 2011.odt" are just to be expected. Another example is the default naming of CF or SD media formatted on certain camera models. Yet another exmaple are customer request.
So far as I understand from the manpage, tmpfiles.d is not so much for cleaning the tmp directory on a regular basis as for creating and managing temporary files and directories on volatile filesystems. I'm
That's what I'm looking for. With F15 the underlying mount point changed from a real filesystem into a tmpfs so I want to utilize tmpfiles.d to create a directory which is expected by some other component. This directory has spaces in its name.
not sure there's really a compelling argument for having this as a request for feature, except if you must have spaces in the temporary directory name for some reason. Being able to use anything you can put in fstab (consistency argument) is probably the only one that flies.
I don't think so. The problem is that certain paths in F15 are suddenly tmpfs paths by default. This potentially clashes with a couple of tools and applications expecting some paths to exist, therefore the tmpfiles.d mechanism has been invented. Unfortunately it doesn't allow to specify *valid* filename characters which might be expected in a filename by a software component not known to the developers.
There is, of course, a workaround by creating the missing directory in some startup script. However, IIUC tmpfiles.d is supposed to be a generic method to create such volatile paths, so it's a pity it doesn't work with some valid pathnames. From my point of view that's a bug.
If you have customers that run unix, care exactly what temporary system locations you use and insist there are spaces in the names then you have very weird customers.
I didn't say anything about my customers. This was merely an example, just like the other ones in my mail. Here's another one: A piece of proprietary software expecting a certain path with spaces in it to run. Again, just an example.
Corinna
On Thu, 2011-06-02 at 10:37 +0200, Corinna Vinschen wrote:
The problem is that certain paths in F15 are suddenly tmpfs paths by default.
I have to wonder whether things that expected to be able to write huge files to temporary disk space are modified to continue to do so, rather than run out of RAM.
As a case in point, I had tried using tmpfs for /tmp, in the past, only to find that I couldn't burn DVDs any more. I didn't have enough RAM to hold the entire disc image that was going to be burnt.
And I dare say that the GIMP may be a problem, if it tries to put huge temp files in RAM, when editing on large image files.
On Wed, 2011-06-01 at 09:59 -0700, JD wrote:
Since a space is Unix's and Linux's chosen field separator, I think having a space in filenames should be avoided. there are many situations where spaces in filenames cause problems. A simple example:
for i in *; do [ -f $i ] && echo $i is a file done
you will see that the file with spaces in it's name will not be recognized as a file because each space-separated member of that file name becomes a separate argument when * is expanded by the shell.
No, each filename counts as one argument, even if it has spaces in it. The problem arises when you *use* the argument. The above should read:
for i in *; do [ -f "$i"] && echo "$i" is a file done
(the quotes are optional in the echo case obviously).
poc
On 06/01/11 12:05, Patrick O'Callaghan wrote:
On Wed, 2011-06-01 at 09:59 -0700, JD wrote:
Since a space is Unix's and Linux's chosen field separator, I think having a space in filenames should be avoided. there are many situations where spaces in filenames cause problems. A simple example:
for i in *; do [ -f $i ]&& echo $i is a file done
you will see that the file with spaces in it's name will not be recognized as a file because each space-separated member of that file name becomes a separate argument when * is expanded by the shell.
No, each filename counts as one argument, even if it has spaces in it. The problem arises when you *use* the argument. The above should read:
for i in *; do [ -f "$i"]&& echo "$i" is a file done
(the quotes are optional in the echo case obviously).
poc
The quotes are not optional. Take a look at this example:
$ ls -1 a b c d j k l m
$ for i in *; do
ls -l $i done
/bin/ls: cannot access a: No such file or directory /bin/ls: cannot access b: No such file or directory /bin/ls: cannot access c: No such file or directory /bin/ls: cannot access d: No such file or directory -rw-r--r-- 1 jd jd 0 Jun 1 12:10 j -rw-r--r-- 1 jd jd 0 Jun 1 12:10 k -rw-r--r-- 1 jd jd 0 Jun 1 12:10 l -rw-r--r-- 1 jd jd 0 Jun 1 12:10 m
$ for i in *; do ls -l "$i" done -rw-r--r-- 1 jd jd 0 Jun 1 12:10 a b c d -rw-r--r-- 1 jd jd 0 Jun 1 12:10 j -rw-r--r-- 1 jd jd 0 Jun 1 12:10 k -rw-r--r-- 1 jd jd 0 Jun 1 12:10 l -rw-r--r-- 1 jd jd 0 Jun 1 12:10 m
I have run into more scripts that had omitted the quotes in the "use" of the variable, and thus failed.
On Wed, Jun 1, 2011 at 3:18 PM, JD jd1008@gmail.com wrote:
On 06/01/11 12:05, Patrick O'Callaghan wrote:
On Wed, 2011-06-01 at 09:59 -0700, JD wrote:
Since a space is Unix's and Linux's chosen field separator, I think having a space in filenames should be avoided. there are many situations where spaces in filenames cause problems. A simple example:
for i in *; do [ -f $i ]&& echo $i is a file done
you will see that the file with spaces in it's name will not be recognized as a file because each space-separated member of that file name becomes a separate argument when * is expanded by the shell.
No, each filename counts as one argument, even if it has spaces in it. The problem arises when you *use* the argument. The above should read:
for i in *; do [ -f "$i"]&& echo "$i" is a file done
(the quotes are optional in the echo case obviously).
poc
The quotes are not optional.
I think he meant that the quotes are optional for the echo $i - which is correct.
Personally I avoid spaces in filenames and usually use a perl one liner to substitute an underscore for spaces when I don't have to keep the original name for someone else.
zsh works without any quotes, the first example works fine for files with spaces in the names with zsh.
Mike
On 1 June 2011 20:30, Mike Williams dmikewilliams@gmail.com wrote:
On Wed, Jun 1, 2011 at 3:18 PM, JD jd1008@gmail.com wrote:
On 06/01/11 12:05, Patrick O'Callaghan wrote:
No, each filename counts as one argument, even if it has spaces in it. The problem arises when you *use* the argument. The above should read:
for i in *; do [ -f "$i"]&& echo "$i" is a file done
(the quotes are optional in the echo case obviously).
The quotes are not optional.
I think he meant that the quotes are optional for the echo $i - which is correct.
Not entirely: $ echo a b a b
Personally I avoid spaces in filenames and usually use a perl one liner to substitute an underscore for spaces when I don't have to keep the original name for someone else.
Yes, in general hours of pain here, especially if you work with people who do lots of shell scripting and another group of people who use Windows lots.
zsh works without any quotes, the first example works fine for files with spaces in the names with zsh.
Might have to look into that, I keep meaning to check out zsh properly.
On Wed, 1 Jun 2011 21:18:15 +0100 Ian Malone wrote:
Yes, in general hours of pain here, especially if you work with people who do lots of shell scripting and another group of people who use Windows lots.
Yea, did anyone notice that Unix/Linux allowed spaces in filenames for years and years before Microsoft invented NTFS, and no one had these problems because no one was foolish enough to actually use spaces in filenames. Then Microsoft was so proud of itself that they said, "Look everyboy, see what I can do! I'm gonna put spaces in everything!". It has been going downhill since then :-).
It also broke a lot of stuff even in Windows. I remember finding all kinds of API documents that claimed an argument was a "filename", but in reality it was some kind of thing fed to a command somewhere that needed the so-called filename to be quoted if it had spaces in it (a minor fact that took years to make it to the documentation for everything, and may still be missing in some Windows APIs).
On Wed, 2011-06-01 at 17:54 -0400, Tom Horsley wrote:
On Wed, 1 Jun 2011 21:18:15 +0100 Ian Malone wrote:
Yes, in general hours of pain here, especially if you work with people who do lots of shell scripting and another group of people who use Windows lots.
Yea, did anyone notice that Unix/Linux allowed spaces in filenames for years and years before Microsoft invented NTFS, and no one had these problems because no one was foolish enough to actually use spaces in filenames.
Not only space of course, but lots of wierd stuff. The only character that can't appear in a filename component is '/'. Everything else is legal, LineFeed, Tab, Del, Ctrl-C, you name it :-)
Returning to the Shell quote thing, in idle moments I sometimes wonder why the Shells don't simply *assume* double quotes around every parameter. No doubt it would break lots of things now, but it might have been a better design to begin with.
poc
On Wed, 2011-06-01 at 18:04 -0430, Patrick O'Callaghan wrote:
The only character that can't appear in a filename component is '/'. Everything else is legal, LineFeed, Tab, Del, Ctrl-C, you name it :-)
And those of us with non-Windows computers would delight in giving Windows users files with a backslash or asterisk in the filename, such as when I ran a BBS on an Amiga, way back in the 1990s.
On 06/01/11 12:30, Mike Williams wrote:
On Wed, Jun 1, 2011 at 3:18 PM, JD <jd1008@gmail.com mailto:jd1008@gmail.com> wrote:
On 06/01/11 12:05, Patrick O'Callaghan wrote: > On Wed, 2011-06-01 at 09:59 -0700, JD wrote: >> Since a space is Unix's and Linux's chosen field separator, >> I think having a space in filenames should be avoided. there >> are many situations where spaces in filenames cause problems. >> A simple example: >> >> for i in *; do >> [ -f $i ]&& echo $i is a file >> done >> >> you will see that the file with spaces in it's name >> will not be recognized as a file because each >> space-separated member of that file name >> becomes a separate argument >> when * is expanded by the shell. > > No, each filename counts as one argument, even if it has spaces in it. > The problem arises when you *use* the argument. The above should read: > > for i in *; do > [ -f "$i"]&& echo "$i" is a file > done > > (the quotes are optional in the echo case obviously). > > poc > The quotes are not optional.I think he meant that the quotes are optional for the echo $i - which is correct.
Personally I avoid spaces in filenames and usually use a perl one liner to substitute an underscore for spaces when I don't have to keep the original name for someone else.
zsh works without any quotes, the first example works fine for files with spaces in the names with zsh.
Mike
Nop! They are not optional for the "use" of the value of the variable, as I clearly demonstrated above.
On Wed, 2011-06-01 at 13:48 -0700, JD wrote:
On 06/01/11 12:39, Patrick O'Callaghan wrote:
On Wed, 2011-06-01 at 12:18 -0700, JD wrote:
The quotes are not optional.
Read my message again.
poc
Did you read my samples of "use" ? Did you see the difference when the quotes were used and when the quotes were not?
Of course I did. You're simply repeating what I said and you seem not to have read carefully. Once again: the quotes are necessary in the use of the variable.
I also mentioned that in the specific application of "echo" as used in your example it didn't make much difference, though as Ian Malone has pointed out there is the case of multiple spaces in the name being collapsed to one. That's technically correct but it's a distinction without a difference for the example input you give*. I'm sorry I even brought it up if it's causing so much confusion.
poc
On 06/01/11 14:15, Patrick O'Callaghan wrote:
On Wed, 2011-06-01 at 13:48 -0700, JD wrote:
On 06/01/11 12:39, Patrick O'Callaghan wrote:
On Wed, 2011-06-01 at 12:18 -0700, JD wrote:
The quotes are not optional.
Read my message again.
poc
Did you read my samples of "use" ? Did you see the difference when the quotes were used and when the quotes were not?
Of course I did. You're simply repeating what I said and you seem not to have read carefully. Once again: the quotes are necessary in the use of the variable.
I also mentioned that in the specific application of "echo" as used in your example it didn't make much difference, though as Ian Malone has pointed out there is the case of multiple spaces in the name being collapsed to one. That's technically correct but it's a distinction without a difference for the example input you give*. I'm sorry I even brought it up if it's causing so much confusion.
poc
Well here's what you said:
No, each filename counts as one argument, even if it has spaces in it. The problem arises when you*use* the argument. The above should read:
for i in *; do [ -f "$i"]&& echo "$i" is a file done
(the quotes are optional in the echo case obviously).
Should have chosen a "use" other than echo :)
but I did indeed misread your post.
Cheers,
JD
-
Corinna Vinschen -
Ian Malone -
JD -
Mike Williams -
Patrick O'Callaghan -
Tim -
Tom Horsley