Does anything for CentOS 8 provide the function of the fstab-decode utility? Entries in /proc/mounts and /etc/fstab can have escape sequences for certain special characters, and I need to decode that.
Am 27.02.22 um 04:33 schrieb Robert Nichols:
Does anything for CentOS 8 provide the function of the fstab-decode utility? Entries in /proc/mounts and /etc/fstab can have escape sequences for certain special characters, and I need to decode that.
Preface: Never heard of fstab-decode before. Researching the command made me really wonder why it was invented. Especially since I have never seen an /etc/fstab with "escape sequences" or "special characters" since at least 1990 (If I am wrong: Please show me such a fstab file).
So why not just use:
umount $(awk '$3 == "vfat" {print $2}' /etc/fstab)
instead of the seemingly canonical use of fstab-decode
fstab-decode umount $(awk '$3 == "vfat" { print $2 }' /etc/fstab)
Myself, I would use the super-standard xargs, that can even take care of the case that there might be no matching lines, that is:
awk '$3 == "vfat" {print $2}' /etc/fstab | xargs -r umount
And if there REALLY are files around with "special characters" I would do it like this:
awk '$3 == "vfat" {ORS="\0" ; print $2}' /etc/fstab | xargs -0 -r umount
I consider this a standard idiom usable for many more use cases than just parsing /etc/fstab....
Peter
On 2/27/22 12:26 PM, centos@niob.at wrote:
Am 27.02.22 um 04:33 schrieb Robert Nichols:
Does anything for CentOS 8 provide the function of the fstab-decode utility? Entries in /proc/mounts and /etc/fstab can have escape sequences for certain special characters, and I need to decode that.
Preface: Never heard of fstab-decode before. Researching the command made me really wonder why it was invented. Especially since I have never seen an /etc/fstab with "escape sequences" or "special characters" since at least 1990 (If I am wrong: Please show me such a fstab file).
So why not just use:
umount $(awk '$3 == "vfat" {print $2}' /etc/fstab)
instead of the seemingly canonical use of fstab-decode
fstab-decode umount $(awk '$3 == "vfat" { print $2 }' /etc/fstab)
Those samples break if the mount point directory name contains spaces, tabs, or whatever other characters I don't know about that also get represented by escape sequences. I'm not actually using it with /etc/fstab, but with /proc/mounts which uses the same convention. I can control /etc/fstab and avoid the problem, but I cannot control how some auto-mounted foreign filesystem might be named. I have a script that needs to be robust in the face of such names.
Am 28.02.22 um 05:45 schrieb Robert Nichols:
On 2/27/22 12:26 PM, centos@niob.at wrote:
Am 27.02.22 um 04:33 schrieb Robert Nichols:
Does anything for CentOS 8 provide the function of the fstab-decode utility? Entries in /proc/mounts and /etc/fstab can have escape sequences for certain special characters, and I need to decode that.
Preface: Never heard of fstab-decode before. Researching the command made me really wonder why it was invented. Especially since I have never seen an /etc/fstab with "escape sequences" or "special characters" since at least 1990 (If I am wrong: Please show me such a fstab file).
So why not just use:
umount $(awk '$3 == "vfat" {print $2}' /etc/fstab)
instead of the seemingly canonical use of fstab-decode
fstab-decode umount $(awk '$3 == "vfat" { print $2 }' /etc/fstab)
Those samples break if the mount point directory name contains spaces, tabs, or whatever other characters I don't know about that also get represented by escape sequences. I'm not actually using it with /etc/fstab, but with /proc/mounts which uses the same convention. I can control /etc/fstab and avoid the problem, but I cannot control how some auto-mounted foreign filesystem might be named. I have a script that needs to be robust in the face of such names.
Get creative! Unix administration is a creative job. Having said this:
Using white space within mount points is asking for trouble anyway. If you really want this in the most generic way, then do the unquoting with something like this:
awk '$3 == "vfat" {print $2}' /etc/fstab | perl -pl000 -e 's/\([0-7]{3})/chr(oct($1))/eg' | xargs -0 -n 1 -r umount
This seems to be the unixy way to do this.
If you really need the fstab-decode program put this in a script (if you want to be able to use commands with arguments you may choose to remove the double quotes in the argument to xargs):
#!/bin/bash # a simple fstab-decode implementation....
CMD="$1" shift
while [ -n "$1" ] ; do echo -E "$1" shift done | perl -pl000 -e 's/\([0-7]{3})/chr(oct($1))/eg;' | xargs -0 -n 1 -r "$CMD"
Peter
On 2/28/22 1:22 AM, centos@niob.at wrote:
Am 28.02.22 um 05:45 schrieb Robert Nichols:
On 2/27/22 12:26 PM, centos@niob.at wrote:
Am 27.02.22 um 04:33 schrieb Robert Nichols:
Does anything for CentOS 8 provide the function of the fstab-decode utility? Entries in /proc/mounts and /etc/fstab can have escape sequences for certain special characters, and I need to decode that.
Preface: Never heard of fstab-decode before. Researching the command made me really wonder why it was invented. Especially since I have never seen an /etc/fstab with "escape sequences" or "special characters" since at least 1990 (If I am wrong: Please show me such a fstab file).
So why not just use:
umount $(awk '$3 == "vfat" {print $2}' /etc/fstab)
instead of the seemingly canonical use of fstab-decode
fstab-decode umount $(awk '$3 == "vfat" { print $2 }' /etc/fstab)
Those samples break if the mount point directory name contains spaces, tabs, or whatever other characters I don't know about that also get represented by escape sequences. I'm not actually using it with /etc/fstab, but with /proc/mounts which uses the same convention. I can control /etc/fstab and avoid the problem, but I cannot control how some auto-mounted foreign filesystem might be named. I have a script that needs to be robust in the face of such names.
Get creative! Unix administration is a creative job. Having said this:
Using white space within mount points is asking for trouble anyway. If you really want this in the most generic way, then do the unquoting with something like this:
awk '$3 == "vfat" {print $2}' /etc/fstab | perl -pl000 -e 's/\([0-7]{3})/chr(oct($1))/eg' | xargs -0 -n 1 -r umount
This seems to be the unixy way to do this.
Yes, white space in mount points is asking for trouble, but if someone automounts a USB flash drive filesystem which has a label that includes white space (e.g.: "USB DISK", like the VFAT preformat on some that I have bought) or other "funny" characters, that label gets used as the mount point directory.
Indeed, I can re-invent the wheel if that wheel is lost in the sands of time.
On 2/28/22 8:46 AM, Robert Nichols wrote:
On 2/28/22 1:22 AM, centos@niob.at wrote:
Am 28.02.22 um 05:45 schrieb Robert Nichols:
On 2/27/22 12:26 PM, centos@niob.at wrote:
Am 27.02.22 um 04:33 schrieb Robert Nichols:
Does anything for CentOS 8 provide the function of the fstab-decode utility? Entries in /proc/mounts and /etc/fstab can have escape sequences for certain special characters, and I need to decode that.
Preface: Never heard of fstab-decode before. Researching the command made me really wonder why it was invented. Especially since I have never seen an /etc/fstab with "escape sequences" or "special characters" since at least 1990 (If I am wrong: Please show me such a fstab file).
So why not just use:
umount $(awk '$3 == "vfat" {print $2}' /etc/fstab)
instead of the seemingly canonical use of fstab-decode
fstab-decode umount $(awk '$3 == "vfat" { print $2 }' /etc/fstab)
Those samples break if the mount point directory name contains spaces, tabs, or whatever other characters I don't know about that also get represented by escape sequences. I'm not actually using it with /etc/fstab, but with /proc/mounts which uses the same convention. I can control /etc/fstab and avoid the problem, but I cannot control how some auto-mounted foreign filesystem might be named. I have a script that needs to be robust in the face of such names.
Get creative! Unix administration is a creative job. Having said this:
Using white space within mount points is asking for trouble anyway. If you really want this in the most generic way, then do the unquoting with something like this:
awk '$3 == "vfat" {print $2}' /etc/fstab | perl -pl000 -e 's/\([0-7]{3})/chr(oct($1))/eg' | xargs -0 -n 1 -r umount
This seems to be the unixy way to do this.
Yes, white space in mount points is asking for trouble, but if someone automounts a USB flash drive filesystem which has a label that includes white space (e.g.: "USB DISK", like the VFAT preformat on some that I have bought) or other "funny" characters, that label gets used as the mount point directory.
Indeed, I can re-invent the wheel if that wheel is lost in the sands of time.
It turns out that particular wheel is best resurrected from the fstab-decode.c file in an old initscripts source package. The encoding is nonstandard, and the above perl code would not handle it correctly. Handling the unlikely oddball case seems like severe paranoia, but this could turn out to be, "That line of code you thought would never be executed just might save the day that one time when it _does_ get executed."
On 3/1/22 05:53, Robert Nichols wrote:
It turns out that particular wheel is best resurrected from the fstab-decode.c file in an old initscripts source package. The encoding is nonstandard, and the above perl code would not handle it correctly.
It's pretty close. It won't handle double backslash, and its use of xargs is incorrect.
If you prefer a version that you don't need a C compiler to use, here's a pure bash implementation:
#!/bin/sh
declare -a cmdline eol=$'\n'
for arg in "$@" do arg="${arg//\011/ }" arg="${arg//\012/$eol}" arg="${arg//\040/ }" arg="${arg//\134/\}" arg="${arg//\/\}" cmdline+=("$arg") done
"${cmdline[@]}"
On 3/1/22 08:52, Gordon Messmer wrote:
If you prefer a version that you don't need a C compiler to use, here's a pure bash implementation:
Chris Schanzle mentioned off-list that a tab character had been replaced with spaces (I *knew* that should have been an attached file, shame on me). He also suggested an improvement that removes the tab character, so here's a second try.
On 3/1/22 10:29, Gordon Messmer wrote:
Chris Schanzle mentioned off-list that a tab character had been replaced with spaces (I *knew* that should have been an attached file, shame on me). He also suggested an improvement that removes the tab character, so here's a second try.
Or not? Last try.
#!/bin/sh
declare -a cmdline tab=$'\t' eol=$'\n'
for arg in "$@" do arg="${arg//\011/$tab}" arg="${arg//\012/$eol}" arg="${arg//\040/ }" arg="${arg//\134/\}" arg="${arg//\\/\}" cmdline+=("$arg") done
"${cmdline[@]}"
On 3/1/22 3:46 PM, Gordon Messmer wrote:
On 3/1/22 10:29, Gordon Messmer wrote:
Chris Schanzle mentioned off-list that a tab character had been replaced with spaces (I *knew* that should have been an attached file, shame on me). He also suggested an improvement that removes the tab character, so here's a second try.
Or not? Last try.
#!/bin/sh
declare -a cmdline tab=$'\t' eol=$'\n'
for arg in "$@" do arg="${arg//\011/$tab}" arg="${arg//\012/$eol}" arg="${arg//\040/ }" arg="${arg//\134/\}" arg="${arg//\\/\}" cmdline+=("$arg") done
"${cmdline[@]}"
The problem there is that the last line is going to get interpreted by a shell before anything is executed, so you now have to escape characters that are special to the shell within a quoted string. This is unlike the compiled fstab-decode program that invokes the execvp() library call and avoids further shell parsing.
On 3/1/22 15:36, Robert Nichols wrote:
"${cmdline[@]}"
The problem there is that the last line is going to get interpreted by a shell before anything is executed, so you now have to escape characters that are special to the shell within a quoted string. This is unlike the compiled fstab-decode program that invokes the execvp() library call and avoids further shell parsing.
Does it, though?
$ bash fstab-decode.sh echo '$PATH' $PATH $ bash fstab-decode.sh ls '*' ls: cannot access '*': No such file or directory
On 3/1/22 7:07 PM, Gordon Messmer wrote:
On 3/1/22 15:36, Robert Nichols wrote:
"${cmdline[@]}"
The problem there is that the last line is going to get interpreted by a shell before anything is executed, so you now have to escape characters that are special to the shell within a quoted string. This is unlike the compiled fstab-decode program that invokes the execvp() library call and avoids further shell parsing.
Does it, though?
$ bash fstab-decode.sh echo '$PATH' $PATH $ bash fstab-decode.sh ls '*' ls: cannot access '*': No such file or directory
After study, the only types of expansion that occur _after_ parameter expansion are word splitting and pathname expansion, and those are both protected by the double quotes. So, I guess it's OK.
-
centos＠niob.at -
Gordon Messmer -
Robert Nichols