Re: [Toybox] Regarding ifconfig
On 02/25/2015 04:15 AM, 김혜진 wrote: Hi. I have a question about ifconfig. Nov 30 on 2013, Rob deleted trailers and dynamic options because they are dead fields unused by linux kernel. But, NOTRAILERS and DYNAMIC string still exist in the code, line from 212 to 214 in ifconfig.c I think these also should be removed if really dead fields. The flags field is set by a call to an ioctl, SIOCGIFFLAGS. The table is the set of labels for the bit positions from /usr/include/linux/if.h: /* Standard interface flags (netdevice-flags). */ #define IFF_UP 0x1 /* interface is up */ #define IFF_BROADCAST 0x2 /* broadcast address valid */ #define IFF_DEBUG 0x4 /* turn on debugging*/ #define IFF_LOOPBACK0x8 /* is a loopback net*/ #define IFF_POINTOPOINT 0x10/* interface is has p-p link*/ #define IFF_NOTRAILERS 0x20/* avoid use of trailers*/ #define IFF_RUNNING 0x40/* interface RFC2863 OPER_UP*/ #define IFF_NOARP 0x80/* no ARP protocol */ #define IFF_PROMISC 0x100 /* receive all packets */ #define IFF_ALLMULTI0x200 /* receive all multicast packets*/ #define IFF_MASTER 0x400 /* master of a load balancer*/ #define IFF_SLAVE 0x800 /* slave of a load balancer */ #define IFF_MULTICAST 0x1000 /* Supports multicast */ #define IFF_PORTSEL 0x2000 /* can set media type */ #define IFF_AUTOMEDIA 0x4000 /* auto media select active */ #define IFF_DYNAMIC 0x8000 /* dialup device with changing addresses*/ Even though a modern kernel should never set the NOTRAILERS or DYNAMIC bits, those are the labels for those bit positions. (I could replace each with but the space savings is trivial. We need something there in each slot to get the spacing right.) Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] I aten't dead.
On Thu, Feb 26, 2015 at 06:26:19AM -0600, Rob Landley wrote:
On 02/25/2015 10:27 AM, Isaac Dunham wrote:
On Wed, Feb 25, 2015 at 03:19:23AM -0600, Rob Landley wrote:
There's a marvelous book called the unix philosophy by mike gancarz
that talks about output intended for humans vs output intended to be
processed by other tools.
A scriptable tool is one where you can do:
echo $(( $(wc -l blah) * 3))
If it's scriptable, the output of one tool is naturally the input to
another. Admittedly this can be annoying to use from the command line
such as the way ls with no arguments will produce no output when run
in an empty directory. But the _reason_ for that is so for i in $(ls);
do blah $i; done doesn't have to filter the ls output to use it in a
script.
Thread hijack/blkid feature I'd like to see (no need to do it now, I'm
willing to try writing it at a later point).
I was just fighting with non-scriptable output in another tool:
blkid.
Which is why fstype exists, although it only gives you the type not the
other attributes.
I'm actually after just the label/just the uuid.
By default it's ROUGHLY shell-quoted, with fields in variable positions
(sample is not actual output, but how it looks):
/dev/sda1: SEC_TYPE=msdos LABEL=ECS_CDRUN UUID=DEAD-BEEF TYPE=vfat
PARTUUID=12345678-01
/dev/sda2: UUID=01234567-abcd-bcde-cdef-0123456789ab SEC_TYPE=ext2
TYPE=ext3 PARTUUID=12345678-02
/dev/sda3: UUID=01234567-abcd-bcde-cdef-0123456789ab TYPE=ext4
PARTUUID=12345678-03
/dev/sdb: LABEL=HA\; `rm -rf /`
UUID=12345678-dcba-bcde-cdef-0123456789ab TYPE=ext4
That's how it does the quoting: around each field, \ before in the
label.
util-linux blkid has a whole bunch of rarely used options,
Which is why I didn't implement them. (That and the lack of standard.)
but two of them
seem to make it a whole lot easier to parse:
-o format output format; can be one of:
value, device, export or full; (default: full)
(They don't mention -o udev here, but it works.)
-s tagshow specified tag(s) (default show all tags)
tag is TYPE/SEC_TYPE/UUID/PARTUUID/LABEL, and means that only
the fields specified get shown, in the same order as usual.
Example:
blkid -s TYPE -s LABEL -s UUID /dev/sda1
/dev/sda1: LABEL=ECS_CDRUN UUID=DEAD-BEEF TYPE=vfat
If it takes a comma separated list and maybe I can get it to share code
with ps -o and mount -o.
No, but a linked list of strings (optstring s*) should work.
(I'm currently filing rough edges off of ps, not yet a proper cleanup
but working my way towards it. I want to implement the bsd ps option
behavior but haven't figured out a graceful way to do it yet. Unlike
with tar, the options mean different things in the different contexts...)
Of the listed output formats,
-o device prints the block device/file and nothing else,
-o export shell-quotes everything:
/sbin/blkid -s LABEL -s UUID -o export /dev/sdb
DEVNAME=/dev/sdb
LABEL=HA\;\ \`rm\ -rf\ /\`
UUID=282e77a6-cbd3-4692-8c62-715c45970377
I notice each field of that is on its own line, and unquoted by default.
Sorry, wrong term. It's escaped not quoted.
-o value uses unquoted strings like this:
blkid -o value -s UUID -s LABEL /dev/sdb
HA; `rm -rf /`
282e77a6-cbd3-4692-8c62-715c45970377
The previous strings were unquoted (although their contents were
escaped), these are unlabeled. (And unescaped.)
-o udev (which uses \xff style quoting) is also available,
but only mentioned in the manpage.
Example:
/sbin/blkid -o udev test.img
ID_FS_LABEL=HArm_-rf_/_
ID_FS_LABEL_ENC=HA\x22\x3b\x20\x60rm\x20-rf\x20\x2f\x60
ID_FS_UUID=282e77a6-cbd3-4692-8c62-715c45970377
ID_FS_UUID_ENC=282e77a6-cbd3-4692-8c62-715c45970377
ID_FS_TYPE=ext2
this is needed for mount by label to work.
I've never understood why anyone does that, but it's not my place to
second guess people's use cases...
I rarely use it, but it can be handy (for example, if you have a couple
flash drives which you want mounted in fixed places).
And the ID_FS_LABEL_ENC field of -o udev matches what I'm looking for
exactly.
I'm confused: what is your use case?
Narrowly:
Populate /dev/disk/by-{label,uuid}/ with symlinks having the same name
that udev gives them, so that mount by label and mount by uuid work right.
Broadly:
I've been working on a package to allow busybox mdev to replace udev
in Debian-based distros, which has already gotten some interest from
others on the Dng list (Dng stands for Debian's not Gnome; it's
the list for Devuan, the fork of Debian over systemd).
Meanwhile, Jude Nelson has been working on a daemon that should
be a replacement for udev (vdev); this will use helper scripts much like
mdev does, and I'm planning to add /dev/disk/by-label/ support for it.
On Debian/Devuan, I know that blkid is provided by util-linux, but
I'd rather be *able* to switch out components.
Re: [Toybox] I aten't dead.
On 02/26/2015 12:01 PM, Isaac Dunham wrote:
On Thu, Feb 26, 2015 at 06:26:19AM -0600, Rob Landley wrote:
On 02/25/2015 10:27 AM, Isaac Dunham wrote:
On Wed, Feb 25, 2015 at 03:19:23AM -0600, Rob Landley wrote:
There's a marvelous book called the unix philosophy by mike gancarz
that talks about output intended for humans vs output intended to be
processed by other tools.
A scriptable tool is one where you can do:
echo $(( $(wc -l blah) * 3))
If it's scriptable, the output of one tool is naturally the input to
another. Admittedly this can be annoying to use from the command line
such as the way ls with no arguments will produce no output when run
in an empty directory. But the _reason_ for that is so for i in $(ls);
do blah $i; done doesn't have to filter the ls output to use it in a
script.
Thread hijack/blkid feature I'd like to see (no need to do it now, I'm
willing to try writing it at a later point).
I was just fighting with non-scriptable output in another tool:
blkid.
Which is why fstype exists, although it only gives you the type not the
other attributes.
I'm actually after just the label/just the uuid.
A properly scriptable solution would be blkid -s label producing
_just_ the label output with no escapes or modifiers (which you could
then pipe through base64 or something if you needed that).
I'm not sure whether your use case is give me this data, behave like
host blkid, or whether the correct solution is to extend mdev.
-s tagshow specified tag(s) (default show all tags)
tag is TYPE/SEC_TYPE/UUID/PARTUUID/LABEL, and means that only
the fields specified get shown, in the same order as usual.
Example:
blkid -s TYPE -s LABEL -s UUID /dev/sda1
/dev/sda1: LABEL=ECS_CDRUN UUID=DEAD-BEEF TYPE=vfat
If it takes a comma separated list and maybe I can get it to share code
with ps -o and mount -o.
No, but a linked list of strings (optstring s*) should work.
I mean if splitting fields at commas won't interfere. (You can already
provide multiple -o to mount.)
And the ID_FS_LABEL_ENC field of -o udev matches what I'm looking for
exactly.
I'm confused: what is your use case?
Narrowly:
Populate /dev/disk/by-{label,uuid}/ with symlinks having the same name
that udev gives them, so that mount by label and mount by uuid work right.
Broadly:
I've been working on a package to allow busybox mdev to replace udev
in Debian-based distros, which has already gotten some interest from
others on the Dng list (Dng stands for Debian's not Gnome; it's
the list for Devuan, the fork of Debian over systemd).
Ooh, possibly I should be subscribed to that list...
Meanwhile, Jude Nelson has been working on a daemon that should
be a replacement for udev (vdev); this will use helper scripts much like
mdev does, and I'm planning to add /dev/disk/by-label/ support for it.
On Debian/Devuan, I know that blkid is provided by util-linux, but
I'd rather be *able* to switch out components.
Being able to switch out components is a strong argument for
compatability, and thus this insanely horrible API the blkid people put
together without the foggiest understanding how to make something
scriptable.
Looking at the blkdev man page: I note that the -d flag is nuts, the -c
and -g options are also nuts (why is this the end user's problem?)...
Huh, the -t option's man page entry is broken:
-t option. If there are multiple devices that match the specified
search parameter, then the device with the highest priority is
returned, and/or the first device found at a given priority.
Device types in order of decreasing priority are Device Mapper,
EVMS, LVM, MD, and finally regular block devices. If this
option is not specified, blkid will print all of the devices
that match the search parameter.
Starts in the middle of a sentence...
How -l and -t are supposed to interact is not clear...
$ sudo blkid /dev/sdb1
/dev/sdb1: LABEL=SEI UUID=6E12-2741 TYPE=vfat
$ sudo blkid -o value -s label /dev/sdb1
$ sudo blkid -o value -s LABEL /dev/sdb1
SEI
And the -s values are case sensitive. Of course they are.
That said, the above appears to be the magic incantation to get LABEL
and UUID fields. I don't have an example of one with an escaped label,
although I point you at the tests/blkid directory if you'd like to
submit one I can poke at.
Would implementing -o value and -s FIELD be sufficient for your purposes?
In theory properly quoted shell strings shouldn't care what their
contents are (modulo NUL bytes and stripping trailing whitespace):
X=$(fruitbat -x)
command $X
Should be fine about having semicolons and quotes and stuff in what $X
expands to...? So the classic definition of scriptable would be not
having any LABEL= at all, but instead having a way to request the
specific field of interest...?
Which is what blkid -s LABEL -o value does.
Is using that bad?
But any of the other
(And if
Re: [Toybox] I aten't dead.
On 02/25/2015 10:27 AM, Isaac Dunham wrote: On Wed, Feb 25, 2015 at 03:19:23AM -0600, Rob Landley wrote: There's a marvelous book called the unix philosophy by mike gancarz that talks about output intended for humans vs output intended to be processed by other tools. A scriptable tool is one where you can do: echo $(( $(wc -l blah) * 3)) If it's scriptable, the output of one tool is naturally the input to another. Admittedly this can be annoying to use from the command line such as the way ls with no arguments will produce no output when run in an empty directory. But the _reason_ for that is so for i in $(ls); do blah $i; done doesn't have to filter the ls output to use it in a script. Thread hijack/blkid feature I'd like to see (no need to do it now, I'm willing to try writing it at a later point). I was just fighting with non-scriptable output in another tool: blkid. Which is why fstype exists, although it only gives you the type not the other attributes. By default it's ROUGHLY shell-quoted, with fields in variable positions (sample is not actual output, but how it looks): /dev/sda1: SEC_TYPE=msdos LABEL=ECS_CDRUN UUID=DEAD-BEEF TYPE=vfat PARTUUID=12345678-01 /dev/sda2: UUID=01234567-abcd-bcde-cdef-0123456789ab SEC_TYPE=ext2 TYPE=ext3 PARTUUID=12345678-02 /dev/sda3: UUID=01234567-abcd-bcde-cdef-0123456789ab TYPE=ext4 PARTUUID=12345678-03 /dev/sdb: LABEL=HA\; `rm -rf /` UUID=12345678-dcba-bcde-cdef-0123456789ab TYPE=ext4 That's how it does the quoting: around each field, \ before in the label. util-linux blkid has a whole bunch of rarely used options, Which is why I didn't implement them. (That and the lack of standard.) but two of them seem to make it a whole lot easier to parse: -o format output format; can be one of: value, device, export or full; (default: full) (They don't mention -o udev here, but it works.) -s tagshow specified tag(s) (default show all tags) tag is TYPE/SEC_TYPE/UUID/PARTUUID/LABEL, and means that only the fields specified get shown, in the same order as usual. Example: blkid -s TYPE -s LABEL -s UUID /dev/sda1 /dev/sda1: LABEL=ECS_CDRUN UUID=DEAD-BEEF TYPE=vfat If it takes a comma separated list and maybe I can get it to share code with ps -o and mount -o. (I'm currently filing rough edges off of ps, not yet a proper cleanup but working my way towards it. I want to implement the bsd ps option behavior but haven't figured out a graceful way to do it yet. Unlike with tar, the options mean different things in the different contexts...) Of the listed output formats, -o device prints the block device/file and nothing else, -o export shell-quotes everything: /sbin/blkid -s LABEL -s UUID -o export /dev/sdb DEVNAME=/dev/sdb LABEL=HA\;\ \`rm\ -rf\ /\` UUID=282e77a6-cbd3-4692-8c62-715c45970377 I notice each field of that is on its own line, and unquoted by default. -o value uses unquoted strings like this: blkid -o value -s UUID -s LABEL /dev/sdb HA; `rm -rf /` 282e77a6-cbd3-4692-8c62-715c45970377 The previous strings were unquoted (although their contents were escaped), these are unlabeled. (And unescaped.) -o udev (which uses \xff style quoting) is also available, but only mentioned in the manpage. Example: /sbin/blkid -o udev test.img ID_FS_LABEL=HArm_-rf_/_ ID_FS_LABEL_ENC=HA\x22\x3b\x20\x60rm\x20-rf\x20\x2f\x60 ID_FS_UUID=282e77a6-cbd3-4692-8c62-715c45970377 ID_FS_UUID_ENC=282e77a6-cbd3-4692-8c62-715c45970377 ID_FS_TYPE=ext2 I'm trying to parse this so I can get links in /dev/disk/by-label/ that match what udev produces; I note I'm in the process of upgrading mdev so I can promote that, but there's a lot of work to do there too. this is needed for mount by label to work. I've never understood why anyone does that, but it's not my place to second guess people's use cases... And the ID_FS_LABEL_ENC field of -o udev matches what I'm looking for exactly. I'm confused: what is your use case? In theory properly quoted shell strings shouldn't care what their contents are (modulo NUL bytes and stripping trailing whitespace): X=$(fruitbat -x) command $X Should be fine about having semicolons and quotes and stuff in what $X expands to...? So the classic definition of scriptable would be not having any LABEL= at all, but instead having a way to request the specific field of interest...? (And if you want a label that's really screwing with mount-by-label, put a / in it.) Thanks, Isaac Dunham Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] I aten't dead.
On Thu, Feb 26, 2015 at 03:19:28PM -0600, Rob Landley wrote:
On 02/26/2015 12:01 PM, Isaac Dunham wrote:
On Thu, Feb 26, 2015 at 06:26:19AM -0600, Rob Landley wrote:
On 02/25/2015 10:27 AM, Isaac Dunham wrote:
On Wed, Feb 25, 2015 at 03:19:23AM -0600, Rob Landley wrote:
There's a marvelous book called the unix philosophy by mike gancarz
that talks about output intended for humans vs output intended to be
processed by other tools.
A scriptable tool is one where you can do:
echo $(( $(wc -l blah) * 3))
If it's scriptable, the output of one tool is naturally the input to
another. Admittedly this can be annoying to use from the command line
such as the way ls with no arguments will produce no output when run
in an empty directory. But the _reason_ for that is so for i in $(ls);
do blah $i; done doesn't have to filter the ls output to use it in a
script.
Thread hijack/blkid feature I'd like to see (no need to do it now, I'm
willing to try writing it at a later point).
I was just fighting with non-scriptable output in another tool:
blkid.
Which is why fstype exists, although it only gives you the type not the
other attributes.
I'm actually after just the label/just the uuid.
A properly scriptable solution would be blkid -s label producing
_just_ the label output with no escapes or modifiers (which you could
then pipe through base64 or something if you needed that).
I'm not sure whether your use case is give me this data, behave like
host blkid, or whether the correct solution is to extend mdev.
-s tagshow specified tag(s) (default show all tags)
tag is TYPE/SEC_TYPE/UUID/PARTUUID/LABEL, and means that only
the fields specified get shown, in the same order as usual.
Example:
blkid -s TYPE -s LABEL -s UUID /dev/sda1
/dev/sda1: LABEL=ECS_CDRUN UUID=DEAD-BEEF TYPE=vfat
If it takes a comma separated list and maybe I can get it to share code
with ps -o and mount -o.
No, but a linked list of strings (optstring s*) should work.
I mean if splitting fields at commas won't interfere. (You can already
provide multiple -o to mount.)
There's no FIELD that includes commas, so I'd assume so.
And the ID_FS_LABEL_ENC field of -o udev matches what I'm looking for
exactly.
I'm confused: what is your use case?
Narrowly:
Populate /dev/disk/by-{label,uuid}/ with symlinks having the same name
that udev gives them, so that mount by label and mount by uuid work right.
Broadly:
I've been working on a package to allow busybox mdev to replace udev
in Debian-based distros, which has already gotten some interest from
others on the Dng list (Dng stands for Debian's not Gnome; it's
the list for Devuan, the fork of Debian over systemd).
Ooh, possibly I should be subscribed to that list...
Meanwhile, Jude Nelson has been working on a daemon that should
be a replacement for udev (vdev); this will use helper scripts much like
mdev does, and I'm planning to add /dev/disk/by-label/ support for it.
On Debian/Devuan, I know that blkid is provided by util-linux, but
I'd rather be *able* to switch out components.
Being able to switch out components is a strong argument for
compatability, and thus this insanely horrible API the blkid people put
together without the foggiest understanding how to make something
scriptable.
Looking at the blkdev man page: I note that the -d flag is nuts, the -c
and -g options are also nuts (why is this the end user's problem?)...
As far as I can tell, most of blkid is nuts. It appears to be an
aggregation of features that have some tangential relationship to
identifying block devices.
I'd just like to know that I can specify -o value or -o udev
and -s LABEL or -s UUID without getting locked into using blkid
from util-linux.
snip
That said, the above appears to be the magic incantation to get LABEL
and UUID fields. I don't have an example of one with an escaped label,
although I point you at the tests/blkid directory if you'd like to
submit one I can poke at.
Would implementing -o value and -s FIELD be sufficient for your purposes?
I think so, though if you support -o value it makes sense to accept
-o full (meaning same as normal).
If it's viable, -o udev would be nice.
In theory properly quoted shell strings shouldn't care what their
contents are (modulo NUL bytes and stripping trailing whitespace):
X=$(fruitbat -x)
command $X
Should be fine about having semicolons and quotes and stuff in what $X
expands to...? So the classic definition of scriptable would be not
having any LABEL= at all, but instead having a way to request the
specific field of interest...?
Which is what blkid -s LABEL -o value does.
Is using that bad?
Only because neither toybox nor busybox implement it.
If either one did, I'd go ahead and use it without a second thought.
But any of the other
(And if you want a label that's really
Re: [Toybox] I aten't dead.
Not sure this is relevant, but I just noticed that on my Debian system my output is a little different from the mentioned outputs. Mainly, it's not quoting or escaping anything, except for the tag_ENC values in -o udev ... Could be a bug, could be version-skewed behavior, but it's a real world example. blkid from util-linux 2.20.1 (libblkid 2.20.0, 19-Oct-2011) $ blkid -o export /dev/sdb5 LABEL=BiggerStorage UUID=7af27f9d-3c38-4bff-826f-fb4589608d53 TYPE=ext4 $ blkid -o udev /dev/sdb5 ID_FS_LABEL=BiggerStorage ID_FS_LABEL_ENC=BiggerStorage ID_FS_UUID=7af27f9d-3c38-4bff-826f-fb4589608d53 ID_FS_UUID_ENC=7af27f9d-3c38-4bff-826f-fb4589608d53 ID_FS_TYPE=ext4 $ blkid /dev/sdb5 /dev/sdb5: LABEL=BiggerStorage UUID=7af27f9d-3c38-4bff-826f-fb4589608d53 TYPE=ext4 $ blkid -o udev -t LABEL=BiggerStorage ID_FS_LABEL=BiggerStorage ID_FS_LABEL_ENC=BiggerStorage ID_FS_UUID=7af27f9d-3c38-4bff-826f-fb4589608d53 ID_FS_UUID_ENC=7af27f9d-3c38-4bff-826f-fb4589608d53 ID_FS_TYPE=ext4 (example with escaped characters needed): $ sudo e2label /dev/sdb5 'Big@$# Storage' Since I'm not flushing cache, rebooting, or running as root, the change will only show up on raw access runs. I forgot how to force that, and I only had a couple of minutes to write this email. $ sudo blkid -p /dev/sdb5 /dev/sdb5: LABEL=Big@$# Storage UUID=7af27f9d-3c38-4bff-826f-fb4589608d53 VERSION=1.0 TYPE=ext4 USAGE=filesystem PART_ENTRY_SCHEME=dos PART_ENTRY_TYPE=0x83 PART_ENTRY_NUMBER=5 PART_ENTRY_OFFSET=976562239 PART_ENTRY_SIZE=400387932 PART_ENTRY_DISK=8:16 $ sudo blkid -p -o udev /dev/sdb5 ID_FS_LABEL=Big@$#_Storage ID_FS_LABEL_ENC=Big@\x24#\x20Storage ID_FS_UUID=7af27f9d-3c38-4bff-826f-fb4589608d53 ID_FS_UUID_ENC=7af27f9d-3c38-4bff-826f-fb4589608d53 ID_FS_VERSION=1.0 ID_FS_TYPE=ext4 ID_FS_USAGE=filesystem ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_TYPE=0x83 ID_PART_ENTRY_NUMBER=5 ID_PART_ENTRY_OFFSET=976562239 ID_PART_ENTRY_SIZE=400387932 ID_PART_ENTRY_DISK=8:16 $ sudo blkid -p -o export /dev/sdb5 LABEL=Big@$# Storage UUID=7af27f9d-3c38-4bff-826f-fb4589608d53 VERSION=1.0 TYPE=ext4 USAGE=filesystem PART_ENTRY_SCHEME=dos PART_ENTRY_TYPE=0x83 PART_ENTRY_NUMBER=5 PART_ENTRY_OFFSET=976562239 PART_ENTRY_SIZE=400387932 PART_ENTRY_DISK=8:16 The extra tags are because I read the raw partition to bypass the cache; the ID_FS_LABEL and ID_FS_LABEL_ENC are the interesting values for this discussion. The example label has a space; -o udev substitutes an underscore in the ID_FS_LABEL tag, but correctly reversibly encodes the full value in the ID_FS_LABEL_ENC value. And -o export has the space but fails to quote or escape it (so it's not actually valid input for eval). -o export would actually be eval-compatible if the value was unquoted, with the following characters preceded with backslash: dollarsign, backquote, doublequote, singlequote, backslash, newline, tab. Untested, but possibly a good idea would be to substitute the appropriate backslash-escape characters such as \a, \b, \t, etc wherever possible. A couple of quick tests show that it's more reliable and simpler to escape characters in the value than to do quoting correctly. It also seems to work better between shells (confirmed in mksh and bash 4.2ish, quick-tested in dash on debian wheezy) Unfortunately (for a past project), there is no tag containing the device path (equivalent to the output of -o device), so if you're using any of the tagged output formats, there's no way to simultaneously get the device and tags when searching by label or uuid. You'd have to do two calls; one to get the device, and one to get the tagged output for that device. Just having a DEVICE=/dev/sdb5 value along with the UUID would have been really convenient for that project. At the moment, I don't have any projects that care about any of this, I just happened to notice it. On Thu, Feb 26, 2015 at 7:04 PM, Isaac Dunham ibid...@gmail.com wrote: On Thu, Feb 26, 2015 at 03:19:28PM -0600, Rob Landley wrote: On 02/26/2015 12:01 PM, Isaac Dunham wrote: On Thu, Feb 26, 2015 at 06:26:19AM -0600, Rob Landley wrote: On 02/25/2015 10:27 AM, Isaac Dunham wrote: On Wed, Feb 25, 2015 at 03:19:23AM -0600, Rob Landley wrote: There's a marvelous book called the unix philosophy by mike gancarz that talks about output intended for humans vs output intended to be processed by other tools. A scriptable tool is one where you can do: echo $(( $(wc -l blah) * 3)) If it's scriptable, the output of one tool is naturally the input to another. Admittedly this can be annoying to use from the command line such as the way ls with no arguments will produce no output when run in an empty directory. But the _reason_ for that is so for i in $(ls); do blah $i; done doesn't have to filter the ls output to use it in a script. Thread hijack/blkid feature I'd like to see (no need to do it now, I'm willing to try writing it at a later point). I was just fighting
