Shell – Understanding fmt (gnu coreutils)

coreutilsshell

I'm using fmt (GNU coreutils) 8.25 and I fail to understand how to use it.
In particular, I don't understand the following results.

$ echo -n "a b c d e" | fmt -w3 -g3

I expected to obtain
```
a b
c d
e
```
but I get
```
a 
b
c 
d
e
```
So I thought maybe fmt counts the linebreak it inserts and tried
$ echo -n "a b c d e" | fmt -w4 -g4

But then, I get:
```
a
b c
d e
```
Finally, I don't get the following:
$ echo -n "a b c d e" | fmt -w4 -g1
which I expected to give
```
a 
b
c 
d
e
```
but instead again results in
```
a
b c
d e
```

So, obviously I'm failing to understand how the -w and -g options work.
Could someone please explain the output of my three examples?

Best Answer

It won't answer your question about coreutils' fmt, but you can solve your string manipulation cases with sed as well:

printf "a b c d e\n" | sed 's/.\{1\} .\{1\} /&\n/g'

result:

a b 
c d 
e

.\{1\} corresponds to a single character.

Related Solutions

Symbolic Links – Trailing Slashes on Symlinks to Directories

The POSIX/Single Unix specification specifies that a pathname with a trailing slash must refer to a directory (see base definitions §4.11 pathname resolution). foo/ is in fact defined as equivalent to foo/. (for path resolution purposes, not when manipulating file names; basename and dirname ignore trailing slashes). Most implementations respect this, but there are a few exceptions.

This explains the behavior of rm this_is_link/: it's equivalent to rm this_is_link/., where the argument is clearly a directory.

rmdir this_is_link/ should similarly refer to the directory. That it doesn't on your machine is a bug in GNU coreutils. OSX is behaving correctly here.

How does coreutil’s date manage to get such weird results

I think it's taking your + x as a time-zone specifier (e.g., consider 2013-04-25 19:52:36 +4 is a valid timestamp, in in a time zone 4 hours ahead of UTC).

It's then seeing the word 'minutes', and treating it as a synonym of minute, so giving you one minute later.

If you put in an explicit timezone specifier, it works:

anthony@Zia:~$ TZ=utc date -d "1970-01-01 00:00:00 UTC" +"%s"   
0
anthony@Zia:~$ TZ=utc date -d "1970-01-01 00:00:00 UTC + 0 minutes" +"%s"
0
anthony@Zia:~$ TZ=utc date -d "1970-01-01 00:00:00 UTC + -1 minutes" +"%s" 
-60
anthony@Zia:~$ TZ=utc date -d "1970-01-01 00:00:00 UTC + 1 minutes" +"%s" 
60

Note the UTC after the seconds field. You can also put in a second +0:

anthony@Zia:~$ TZ=utc date -d "1970-01-01 00:00:00 +0 + -1 minutes" +"%s"
-60

... but at least personally, that's much harder to read.

Or you can put a Z after the seconds, etc. You don't actually need the TZ environment variable to be set to UTC in the above examples.

Best Answer

Related Solutions

Symbolic Links – Trailing Slashes on Symlinks to Directories

How does coreutil’s date manage to get such weird results

Related Question