bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11922: df doesn't handle \n in mount entries appropriately


From: Pádraig Brady
Subject: bug#11922: df doesn't handle \n in mount entries appropriately
Date: Thu, 12 Jul 2012 12:50:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

The edge case where '\n' is in any of the /proc/mounts fields,
will cause problems with errant new lines being output by `df`.
(I notice `findmnt` from util-linux too has the same issue).

So df uses getmntent(3) to get the list, and from its man page we have:

"Since fields in the mtab and fstab files are separated  by  whitespace,
octal  escapes  are used to represent the four characters space (\040),
tab (\011), newline (\012) and backslash (\134)  in  those  files  when
they  occur in one of the four strings in a mntent structure.  The rou‐
tines addmntent() and getmntent() will convert from string  representa‐
tion to escaped representation and back."

So how to handle this. I don't think it's appropriate to
reapply all the escaping in -P mode (which explicitly wants to avoid
multiline entries), since scripts might already be
handling the more common cases of <space> and <tab>.
So how about we just change \n -> \012.
This will at least improve the output for humans.
Scripts will not be able to directly use such entries,
but they couldn't anyway, and also processing of other
entries is no longer impacted.

Also `df` since coreutils 8.11 no longer wraps long lines,
preferring to expand alignment. This is easier to read
and avoids a common gotcha in scripts.
So even for non -P mode, we should do the \n -> \012 change.

It's tempting to do this transformation in read_file_system_list()
in gnulib, but that would cause that lib to output an ambiguous
format, and so it's probably best do the processing in each app
as required?

cheers,
Pádraig.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]