2

I have found that white space seems to be significant in ZFS commands, but only apparently under some conditions.. For example, both of the following commands work:

root@grandidier:~# zfs list -t snap -r tank/srv 
NAME                  USED  AVAIL  REFER  MOUNTPOINT
tank/srv@initial     4.22G      -  2.45T  -
tank/srv@2018-01-09   106G      -  3.40T  -
tank/srv@2018-01-14  50.0M      -  3.27T  -
tank/srv@2018-01-17  48.8M      -  3.16T  -
tank/srv@2018-01-19  56.9M      -  3.09T  -
tank/srv@2018-01-30  48.6M      -  2.72T  -
tank/srv@2018-02-12   104M      -  2.49T  -
root@grandidier:~# zfs list -t snap  -r tank/srv 
NAME                  USED  AVAIL  REFER  MOUNTPOINT
tank/srv@initial     4.22G      -  2.45T  -
tank/srv@2018-01-09   106G      -  3.40T  -
tank/srv@2018-01-14  50.0M      -  3.27T  -
tank/srv@2018-01-17  48.8M      -  3.16T  -
tank/srv@2018-01-19  56.9M      -  3.09T  -
tank/srv@2018-01-30  48.6M      -  2.72T  -
tank/srv@2018-02-12   104M      -  2.49T  -
root@grandidier:~#

(Note: added space between "...snap -r") However if I put the command in a pipe and use back tick substitution to get the result of the command, I get:

root@grandidier:~# export NEW=`zfs list -t snap -r tank/srv | tail -1 | awk '{print $1}'`; echo $NEW
tank/srv@2018-02-12
root@grandidier:~# export NEW=`zfs list -t snap  -r tank/srv | tail -1 | awk '{print $1}'`; echo $NEW
cannot open ' -r': invalid dataset name
cannot open 'tank/srv': operation not applicable to datasets of this type

root@grandidier:~# 

I find this baffling and disconcerting. I think I can sidestep the issue by crafting my scripts without any extra white space but I'd really like to know why this is happening in the first place.

This is on
Ubuntu 16.04 LTS (up to date)
bash 4.3.48
ZFS 0.6.5.11-1ubuntu3

Edit: to answer the first three comments (and retain code formatting)

root@grandidier:~/bin# printf '%q\n' "$IFS"
$' \t\n'

It seems that the $(...) syntax is also subject to this problem (see next comment.)

I'm not sure where something that looks like a space could come from but it seems that is the issue. I have copied this string to/from a Google doc and perhaps it did some sort of translation on the spaces. If I add the extra space in the google doc and copy/paste to an xterm, the error is reported. If I edit the command (on the command line) and delete/reenter the two spaces, the command works w/out error.

Clearly Google Docs is not a good programming editor. (I'm not really using it that way but rather to take notes and save copies of commands as I work my way through something. I probably should stick to something like vim for that.)

  • 1
    What is the value of $IFS? You can run printf '%q\n' "$IFS" to find out. – wjandrea Feb 13 '18 at 18:22
  • Try using the newer command substitution syntax $() instead of backticks. – wjandrea Feb 13 '18 at 18:22
  • 1
    That second space in the second example is probably not an actual space but an NBSP or similar Unicode space – muru Feb 13 '18 at 22:36
  • 1
    Yep, Google Docs would be it. Any "rich text" editor would cause problems with code, such as converting -- to en-dashes, normal spaces to NBSP, normal quotes to pretty quotes, etc. Maybe use a monospace font or something. – muru Feb 14 '18 at 2:15
  • 1
    Looks like it's been converted into a regular space in your question. If you want to find out what Unicode character it is, you can pipe the string into uniname, like echo "  " | uniname (this is an example with two regular spaces). – wjandrea Feb 14 '18 at 19:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.