mount output format for a script

[Dominique Michel]

Adding FreeBSD support into Fvwm-Crystal. It have a Preferences -> Desktop manager -> FVWM-Crystal functionality that generate on the fly a fvwm config to show icons on the desktop. It have its own preferences system (right click) which contain Mounted partitions On/Off. When On, it will use mount to show one icon per mounted partition and another check to filter in only the paritions the user have access to. On my system:

% mount
zroot/ROOT/default on / (zfs, local, noatime, nfsv4acls)
devfs on /dev (devfs)
zroot/home on /home (zfs, local, noatime, nfsv4acls)
zroot/usr/ports on /usr/ports (zfs, local, noatime, nosuid, nfsv4acls)
zroot/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/var/mail on /var/mail (zfs, local, nfsv4acls)
zroot/var/crash on /var/crash (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/usr/src on /usr/src (zfs, local, noatime, nfsv4acls)
zroot/var/log on /var/log (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/audit on /var/audit (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot on /zroot (zfs, local, noatime, nfsv4acls)
zroot/var/tmp on /var/tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/home/dom on /home/dom (zfs, local, noatime, nfsv4acls)

The mounted partition test, filter out all partitions that don't begin by a '/' or a list of words:

mount | gawk '/^\/.*|^(simple-mtpfs|http|zroot).*\// { print "" "" $3 "" ""; }' |sort

I am not sure is I want to keep zroot as it into that list (simple-mtpfs|http|zroot), that because it show everything but devfs on the desktop, of them, the only one really useful for the user is zroot/home/<user>, which is already included into these icons and is the only one icon that cannot be disabled into the preferences. It is also a Show directories where the user can define his own icon launchers with custom paths.

My questions: Will all the mounted partitions begin with zroot? What will be mount output for the distant mounted partitions, will their names begin with 'http' as on linux, 'zroot/http' or something else? What else can be useful?

 

[SirDice]

Will all the mounted partitions begin with zroot?

Only on the default ZFS install because 'zroot' is the name of the pool the installer created. Which is common to use but certainly not enforced, so custom installs may have an entirely different pool name.

 

[Deleted member 81054]

Only on the default ZFS install because 'zroot' is the name of the pool the installer created. Which is common to use but certainly not enforced, so custom installs may have an entirely different pool name.

Couldn't you examine the location of the "/" mount and extract that (iff all installs are ZFS-based)?

 

[covacat]

you can use mount -p
easier to parse
fstype will be $3 in awk speak

 

[cracauer@]

This gets very complicated when there are sequences of multiple spaces in the names.

Might be easier to use C and the getfsstat(2) system call.

 

[Dominique Michel]

Couldn't you examine the location of the "/" mount and extract that (iff all installs are ZFS-based)?

It is a good clue, thanks.

 

[Dominique Michel]

you can use mount -p
easier to parse
fstype will be $3 in awk speak

mount -p is illegal on linux. Also, I am not interested by the mount type because fvwm-crystal don't mess with the system. To test for access is both simpler and better, but it's another test. Here all I want is the mount point.

It is the responsibility of the sysadmin to mount the partitions or to setup some automount mechanism. All that can do these partitions icons is to launch a file manager or a custom action defined into the preferences. 2 actions can be defined.

 

[Dominique Michel]

This gets very complicated when there are sequences of multiple spaces in the names.

Might be easier to use C and the getfsstat(2) system call.

I don't know C/C++. Also bash is well behaving with spaces in values when the variables are correctly quoted. It is more complicated with special characters. Here, in strings like

devfs on /dev (devfs)
zroot/home on /home (zfs, local, noatime, nfsv4acls)

I consider spaces into the file system names or mount points like bugs into the implementation of the system.

 

[ralphbsz]

I don't know C/C++. Also bash is well behaving with spaces in values when the variables are correctly quoted.

Sadly, the output of mount (and of mount -p) does not quote variables.

I consider spaces into the file system names or mount points like bugs into the implementation of the system.

Nothing prevents me from mounting /dev/ada1p2 on "/home/foo bar/". Even better, I can create a directory "/home/foo\nbar" (with a newline in the name!), and mount a file system on it. Then when parsing the output of mount you will see two incomplete lines. Nothing prevents me from creating a device called "/dev/ada blatz fish" and mounting it on /mnt/cdrom. Both those are easy to do when using UFS. With ZFS, I don't know whether a pool or dataset name can have spaces in it (and I'm too lazy to find out). Remember, only two characters are illegal in file names (and therefore mount points): nul and "/".

Footnote: These days with the dev file system, it is actually pretty hard to create a new device that has an arbitrary name in /dev, and I don't know whether one can still use device nodes that are stored outside of /dev, haven't tried either in ages. And I wouldn't be at all sad if that was illegal.

Obnoxious remark: I think Windows got it right when it prohibited many special characters in file names. If I were the dictator, I would prohibit anything other than displayable 7-bit ASCII, or go right to guaranteed unique 128-bit numbers as file IDs, like many object store systems do. The place for nice, long, human-readable strings is not in OS interfaces. Fortunately for the rest of the world, I'm not the dictator.

 

[Deleted member 81054]

I think Windows got it right when it prohibited many special characters in file names.

Like ':'? Or, '?'?

It's annoying when an interface places ARBITRARY limits on what you can do. Why should "." and ".." have the meanings that they do? Wouldn't '^' be more meaningful? (Or, '>' and '<' to move down and up a hierarchy, respectively?)

I would prohibit anything other than displayable 7-bit ASCII,

My current system uses separate namespaces for each process/task. Within a given "context" (what windows would call a folder), names are just arbitrary strings arrays of bytes. There's nothing to prevent a context from having names like 1r16, 2r16, 3r16, etc. If the only consumer of those objects is a piece of code, then why shoul dit have to come up with "human readable" names for the objects with which it is interacting?

Why use '/' (or '\' or '>') to separate contexts (i.e., levels in the hierarchy)? The developer knows the characteristics of the namespace he will be given so he can interpret the names therein any way that is appropriate! E.g., he knows that "outputs" is a context (i.e. folder) that holds the outputs of his application while "inputs" is a context that holds the inputs.

Getting rid of ".." also gets rid of a whole class of potential problems (how do you unambiguously know what's ABOVE this?)

 

[cy@]

Like ':'? Or, '?'?

It's annoying when an interface places ARBITRARY limits on what you can do. Why should "." and ".." have the meanings that they do? Wouldn't '^' be more meaningful? (Or, '>' and '<' to move down and up a hierarchy, respectively?)

This is because,

a) . and .. are the first two files (inode pointers) in the directory. They are actual hard links to the current directory and to the parent.
b) can you imagine if < and > had special meaning WRT directories. How would that work with shell redirection?

My current system uses separate namespaces for each process/task. Within a given "context" (what windows would call a folder), names are just arbitrary strings arrays of bytes. There's nothing to prevent a context from having names like 1r16, 2r16, 3r16, etc. If the only consumer of those objects is a piece of code, then why shoul dit have to come up with "human readable" names for the objects with which it is interacting?

Why use '/' (or '\' or '>') to separate contexts (i.e., levels in the hierarchy)? The developer knows the characteristics of the namespace he will be given so he can interpret the names therein any way that is appropriate! E.g., he knows that "outputs" is a context (i.e. folder) that holds the outputs of his application while "inputs" is a context that holds the inputs.

You have to use something. UNIX uses /. The mainframe uses a dot. Every O/S has its convention.

Getting rid of ".." also gets rid of a whole class of potential problems (how do you unambiguously know what's ABOVE this?)

Huh?? Really?!

 

[cy@]

Sadly, the output of mount (and of mount -p) does not quote variables.

It doesn't have to. I wrote two python scripts for Linux as part of an ansible role. And, it took a couple of minor tweaks to make those two python cripts (and ansible roles) work on FreeBSD. And what did those two python scripts do might you ask? One produced CSV files reporting the state of mounted filesystems while the other reported the state of NFS shares. Their output was emailed to me (by ansible). I simply opened each file in Excel.

I really don't understand what the problem is in this thread. It's a simple problem that took about an hour to write in python and ansible to produce CSV (Excel) files.

 

[Deleted member 81054]

This is because,

...because of some arbitrary convention adopted by the system's designers.

Every O/S has its convention.

Yes. And, given that there are multiple OSs in use, today, having different rules for each means there is NO convention.

Try unpacking a tarball onto a Windows machine and wondering why Makefile, makefile and MAKEFILE have been replaced by ONE file having a name of that sort.

Or, wondering why "a/really/really/really/long/pathname" is not accessible. But, MAY be if a different application tries to do so!

Huh?? Really?!

Two symlinks (or, hardlinks if the filesystem structure will tolerate it) existing in different parts of the hierarchy each reference a particular entry. You try to go ".." from there. Where do you end up? Likely NOT where you started from!

If you need to access "..", then take (and hold) a direct reference to it so you know what it resolves to.

Parsing the path "a/path/name/.." can give you a different result than changing to "a/path/name" and trying to "cd .."

 

[Erichans]

mount -p is illegal on linux. [...] Here all I want is the mount point

If all installs are ZFS-based; using zfs-list(8) & sed(8):
zfs list -o mounted,mountpoint -H | sed -n '/^yes/ s/^yes\t\(.*\)/\1/p'
or
zfs list -o mounted,mountpoint -H | awk '/^yes/ { sub(/^yes\t/,""); print $0 }'
This should cover most "irregular" characters (except most likely "\n" in the mountpoint string), and should also work on Linux.

 

[cy@]

...because of some arbitrary convention adopted by the system's designers.

Yeah, so what?

Yes. And, given that there are multiple OSs in use, today, having different rules for each means there is NO convention.

Ahh. Then pick an O/S and and only use it (homogeneously).

POSIX addressed the UNIX variants. And, ok, the various vendors and now open source projects have gone their own ways. It's a diverging landscape

Try unpacking a tarball onto a Windows machine and wondering why Makefile, makefile and MAKEFILE have been replaced by ONE file having a name of that sort.

make(1) understands all the names and uses them.

The bigger problem is M$'s make is not compatible with GNU make which is not compatible with bmake which is not compatible with <pick your make>.

Or, wondering why "a/really/really/really/long/pathname" is not accessible. But, MAY be if a different application tries to do so!


Two symlinks (or, hardlinks if the filesystem structure will tolerate it) existing in different parts of the hierarchy each reference a particular entry. You try to go ".." from there. Where do you end up? Likely NOT where you started from!

This is an implementation issue. When reversing up the tree some shells use realpath() while others do not. That can be an annoyance.

If you need to access "..", then take (and hold) a direct reference to it so you know what it resolves to.

Parsing the path "a/path/name/.." can give you a different result than changing to "a/path/name" and trying to "cd .."

Again, some shells call getcwd(3) while others call realpath(3). Depending on how the developers of that shell implemented referencing relative paths, whether they used getcwd() or realpath(), the result will be different. And yes, I agree this should have been a POSIX standard. Sadly it's not.

I suppose if you want to pick a standard, let's use the most common desktop O/S as a basis for a global desktop standard. And that O/S isn't Linux (or any UNIX). And even with that O/S -- it's Windows BTW -- look at the structure of their directories. MS-DOS and subsequently Windows chose to copy the UNIX approach WRT directory structure.

 

[Deleted member 81054]

I suppose if you want to pick a standard, let's use the most common desktop O/S as a basis for a global desktop standard.

No. The application should define how it interprets names, not the OS. Folks who are stuck working within the constraints of an existing OS don't have that freedom -- and it is reflected in their applications.

These "conventions" are artifacts of design decisions made 50 years ago. Really? We haven't come up with any new ideas in half a century? (sure we have, but folks are ignorant of them and slow/resistant to adopting them). A single SHARED namespace? How is that a good approach to designing a system? And, we'll just layer ACLs on top of that to keep users/actors/agents out of things that they shouldn't be accessing (wouldn't it be simpler just to NOT SHOW THEM to those agents?)

The OS should support the application, not constrain it. The application, in turn, should support the user's problem space instead of constraining how the user addresses those problems.

This allows the user (who likely is NOT a developer/programmer/engineer) to solve his problem without adopting the notions of a developer/programmer/engineer who is likely ignorant of them.

 

[Dominique Michel]

If all installs are ZFS-based; using zfs-list(8) & sed(8):
zfs list -o mounted,mountpoint -H | sed -n '/^yes/ s/^yes\t\(.*\)/\1/p'
or
zfs list -o mounted,mountpoint -H | awk '/^yes/ { sub(/^yes\t/,""); print $0 }'
This should cover most "irregular" characters (except most likely "\n" in the mountpoint string), and should also work on Linux.

Thanks, I will try it. I can add an uname or zfs presence test into the script.

 

[Dominique Michel]

Most Unix like systems are following the FSH, that with a lot of variations. But the user can and will do anything into their home, including files or directories with spaces into their names. Which imply spaces in names should not be an issue for the show partitions part of these icons, but is definitely one with the show directories part. But that's another issue.

 

[Dominique Michel]

Nothing prevents me from mounting /dev/ada1p2 on "/home/foo bar/". Even better, I can create a directory "/home/foo\nbar" (with a newline in the name!), and mount a file system on it. Then when parsing the output of mount you will see two incomplete lines. Nothing prevents me from creating a device called "/dev/ada blatz fish" and mounting it on /mnt/cdrom. Both those are easy to do when using UFS. With ZFS, I don't know whether a pool or dataset name can have spaces in it (and I'm too lazy to find out). Remember, only two characters are illegal in file names (and therefore mount points): nul and "/".

Obnoxious remark: I think Windows got it right when it prohibited many special characters in file names. If I were the dictator, I would prohibit anything other than displayable 7-bit ASCII, or go right to guaranteed unique 128-bit numbers as file IDs, like many object store systems do. The place for nice, long, human-readable strings is not in OS interfaces. Fortunately for the rest of the world, I'm not the dictator.

Maybe I should use the associative bash arrays then. But if mount output is bailing with spaces into the names, I can wait until it's fixed. And yep, I am the dictator with fvwm-crystal.

My only requirement for people that want to join is to not mess with existing user preferences, or if You do so with the fvwm-crystal preferences (I done it one time), provide an automatic background conversion from the old preferences system to the new one.

 

[cy@]

No. The application should define how it interprets names, not the OS. Folks who are stuck working within the constraints of an existing OS don't have that freedom -- and it is reflected in their applications.

Have you read any of what I wrote? Especially the part about getcwd() and realpath()? Obviously not!

 

[Deleted member 81054]

I deliberately chose that as an example. Think about it.