[Toybox] I aten't dead.

[Robert Thompson]

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.ag at 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 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 <tag>    show 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 screwing with mount-by-label,
> put
> > >> a / in it.)
> > >
> > > udev/blkid -o udev handles this by converting all "unsafe" chars to
> > > "\x<hex value>" so a label "/" becomes "/dev/disk/by-label/\x2f".
> >
> > Hmmm, I remember there being a way to do that...
> >
> > Not cat -v, not uuencode, not base64... grrr, I remember having done it,
> > but not how. And of course with blkid -o format controls _both_ labeling
> > and escaping without any orthogonal control for the specific field.
> > Because they hate Don Norman.
> >
> > > Thanks,
> > > Isaac Dunham
> >
> > Rob
> Isaac Dunham
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20150226/693ae064/attachment-0004.htm>