Bug 191611 - getmntent(3): does not state /etc/fstab quoting rules correctly
Summary: getmntent(3): does not state /etc/fstab quoting rules correctly
Status: RESOLVED CODE_FIX
Alias: None
Product: Documentation
Classification: Unclassified
Component: man-pages (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: documentation_man-pages@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-31 08:25 UTC by anders
Modified: 2017-01-05 04:20 UTC (History)
1 user (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description anders 2016-12-31 08:25:29 UTC
The current man page says:

"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
routines addmntent() and getmntent() will convert from string
representation to escaped representation and back."

* Problem:

The currrent source of glibc (2.24, file misc/mntent_r.c) does things slightly differently:

It encodes \  (backslash) into '\\', not  into '\134'.

it decodes both '\\' and '\134' into \ (backslash).

It looks very much like the currently preferred encoding of backslash is '\\', as that's the only one that works both ways.

* Suggestion: 

Change '(\134)' in the cited passage to '(\\)', and add a note after the cited paragraph that '\134' is also allowed on reading.

Note: 

('\134' is an odd octal escape, as it doesn't start with '\0' ...)
Comment 1 Michael Kerrisk 2017-01-05 04:20:02 UTC
Thanks. I made the text:

       Since fields in the mtab and fstab files are separated  by  white‐
       space,  octal  escapes  are used to represent the characters space
       (\040), tab (\011), newline (\012), and backslash  (\\)  in  those
       files  when  they  occur  in  one  of the four strings in a mntent
       structure.  The routines addmntent() and getmntent() will  convert
       from  string  representation  to  escaped representation and back.
       When converting from escaped representation, the sequence \134  is
       also converted to a backslash.

I think this fixes your issue, so I'm closing this bug. Please reopen if you see something still to fix.

Note You need to log in before you can comment on or make changes to this bug.