I used an external editor to complete the above and it looks like the final text, which did display correctly in the edit field before I submitted it, was nevertheless truncated where I invoked the external editor, so apologies for that, and I'll stick to in-browser editing now. It should go on to say: "... or the facility to pipe the mountpoint string through an external process such as a shell script before insertion, or both. Thank you."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
di -f M will display the full width of the mount points.
Likewise, -f S will display the complete filesystem name.
e.g. di -f MSbuvpT
For post processing, the -c flag can be used to output CSV formatted values, or the -j flag for JSON output. This can be piped into a program to process it.
Does this meet your needs?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the suggestion, but no, I don't think that will suffice, since I already have M in my $DI_ARGS (sMbuv1t, to be precise).
Before I made the edit documented in my second comment above, then recompiled and reinstalled, my listed mountpoints were all truncated to 15 characters. Now they are not.
For mountpoints under /run/media/phil/, (that is, those mounted automatically or by the udisk subsystem on Linux), all that was visible in the mountpoint field was precisely /run/media/phil, which happens to be 15 characters -- no use at all, especially when more than one such mountpoint is active and they all appear with exactly the same mountpoint string.
My idea about piping was that di should be able to call out to a shell script during each iteration of its own row-formatting loop and use the output inline, so that I might (for instance) shorten all udisk mountpoints as "/r/m/p/mountname1", "/r/m/p/mountname2" etc, using sed or awk. This is only needed if the mountpoint field width cannot be configured. I could instead use the grc/grcat command line tool to pipe di's output through for the same effect, but only if di is actually outputting more than just "/run/media/phil" for each mountpoint there, which again only works (but will not then be neede) if di is actually outputting the full mountpoint.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That sounds very odd, as the -f M flag uses the maximum width, and changing the value of 15 will have no effect. Can you show me the output of "echo $DI_ARGS"?
bll-g7:bll$ DI_ARGS="-f sMt" ./C/di # uses max width of mount point
Filesystem Mount fsType
/dev/nvme0n1p7 / ext4
/dev/nvme0n1p1 /boot/efi vfat
/dev/sda2 /home ext4
bll-g7:bll$ DI_ARGS="-f smt" ./C/di # uses a field width of 15
Filesystem Mount fsType
/dev/nvme0n1p7 / ext4
/dev/nvme0n1p1 /boot/efi vfat
/dev/sda2 /home ext4
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Boy do I feel stupid. I just realized that my DI_ARGS was missing '-f' before the format specifier string, and that it has been missing for many years. Sorry for the noise and please close.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And I think calling a process per-line is not really necessary since the CSV and JSON output is available. That would be overly complicated for this utility.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I used an external editor to complete the above and it looks like the final text, which did display correctly in the edit field before I submitted it, was nevertheless truncated where I invoked the external editor, so apologies for that, and I'll stick to in-browser editing now. It should go on to say: "... or the facility to pipe the mountpoint string through an external process such as a shell script before insertion, or both. Thank you."
For anyone else who wants a quick-and-dirty fix for this now, change the hard-coded literal 15 at line 1126 of display.c to whatever you want.
di -f M will display the full width of the mount points.
Likewise, -f S will display the complete filesystem name.
e.g. di -f MSbuvpT
For post processing, the -c flag can be used to output CSV formatted values, or the -j flag for JSON output. This can be piped into a program to process it.
Does this meet your needs?
Thanks for the suggestion, but no, I don't think that will suffice, since I already have M in my $DI_ARGS (sMbuv1t, to be precise).
Before I made the edit documented in my second comment above, then recompiled and reinstalled, my listed mountpoints were all truncated to 15 characters. Now they are not.
For mountpoints under /run/media/phil/, (that is, those mounted automatically or by the udisk subsystem on Linux), all that was visible in the mountpoint field was precisely /run/media/phil, which happens to be 15 characters -- no use at all, especially when more than one such mountpoint is active and they all appear with exactly the same mountpoint string.
My idea about piping was that di should be able to call out to a shell script during each iteration of its own row-formatting loop and use the output inline, so that I might (for instance) shorten all udisk mountpoints as "/r/m/p/mountname1", "/r/m/p/mountname2" etc, using sed or awk. This is only needed if the mountpoint field width cannot be configured. I could instead use the grc/grcat command line tool to pipe di's output through for the same effect, but only if di is actually outputting more than just "/run/media/phil" for each mountpoint there, which again only works (but will not then be neede) if di is actually outputting the full mountpoint.
That sounds very odd, as the -f M flag uses the maximum width, and changing the value of 15 will have no effect. Can you show me the output of "echo $DI_ARGS"?
Boy do I feel stupid. I just realized that my DI_ARGS was missing '-f' before the format specifier string, and that it has been missing for many years. Sorry for the noise and please close.
No worries.
And I think calling a process per-line is not really necessary since the CSV and JSON output is available. That would be overly complicated for this utility.