Re: question related to cp (-p) and /tmp

["Thomas Schmitt" <scdbackup@gmx.net>]

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