Hi,
i wrote:
> > > setfattr -n system.nfs4_acl -v
> > > '\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0' /tmp/x
Max Nikulin wrote:
> Shell does not interpret backslashes in single (and double) quotes.
Non-interpretation by the shell was my intention. I wanted the string
to reach setfattr(1) literally.
Inspiration was this line from strace:
fsetxattr(5, "system.nfs4_acl",
"\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0", 80, 0) = -1
Greg Wooledge wrote:
> Thomas's command is *relying* on setfattr interpreting the backslash
> sequences, because the shell cannot be allowed to do so.
Indeed. The man page supports me modulo artistic freedom.
-v value, --value=value
[...] If the given string is
enclosed in double quotes, the inner string is treated as text. In
that case, backslashes and double quotes have special meanings [...]
I omitted the double quotes but obviously my value was decoded as i
intended:
$ getfattr -d /tmp/x
getfattr: Removing leading '/' from absolute path names
# file: tmp/x
user.x=0sAAAAAwAAAAAAAAAAABYBpwAAAAZPV05FUkAAAAAAAA==
$ base64 -d | hxd
AAAAAwAAAAAAAAAAABYBpwAAAAZPV05FUkAAAAAAAA==
<Ctrl+d>
00000000 : 00 00 00 03 00 00 00 00 00 00 00 00 00 16 01 a7
0 : 0 0 0 3 0 0 0 0 0 0 0 0 0 22 1 167
00000010 : 00 00 00 06 4f 57 4e 45 52 40 00 00 00 00 00
O W N E R @
16 : 0 0 0 6 79 87 78 69 82 64 0 0 0 0 0
This looks much like i would expect from correct decoding of the octal
salad text. (hxd is my own binary dumper for hex, cleartext, and decimal.
In a rogue ISO 9660 filesystem one never knows which byte presentation
brings the decisive insight.)
Have a nice day :)
Thomas
