[lsb-discuss] Is getmntent() not in the standard?

Nick Stoughton nick at usenix.org
Mon Oct 16 09:35:48 PDT 2006

On Mon, 2006-10-16 at 16:08 +0200, Jiri Dluhos wrote:
> Hello all,
> I have tried to build coreutils with lsbcc and found that the configure script 
> is not able to find any system call to determine the mounted filesystems; I 
> believe this should be getmntent() on Linux.
> And indeed, it is not in LSB headers. I even could not find it in the specs; 
> is it possible that this function is not part of the standard? If it is, do 
> we have any other way of determining mounts?
> Thank you for any info,
> Best regards,
>     Jiri Dluhos
The LSB database is the source of all information in the LSB.

getmntent_r is in the database, as 'defered' (along with hasmntopt).
Interestingly, the man page for getmntent on my system claims "LSB
deprecates the functions endhostent(), sethostent() and setmntent()."
but the database says different! (and one wonders why this page mentions
sethostent and endhostent, and not setmntent and endmntent).

mysql> select Iname, Istatus, Iwithdrawnin from Interface where Iname

| Iname       | Istatus  | Iwithdrawnin |
| endhostent  | Excluded | none         |
| getmntent_r | Defered  | none         |
| sethostent  | Excluded | none         |
3 rows in set (0.11 sec)
mysql> select Iname, Istatus, Iwithdrawnin from Interface where Iname
like '%mnt%';
| Iname       | Istatus | Iwithdrawnin |
| getmntent_r | Defered | none         |
| hasmntopt   | Defered | none         |
2 rows in set (0.11 sec)

As Mats said, these have been discussed in the past, and file system
mounting (and things related to it) was rejected as a 'System Admin'
utility ... although actually that is not the whole of it.

In general, portable applications do not care about what file system is
mounted where. A couple of utilities (such a 'df'), and particular
utilities in coreutils, DO care, but they are rare, and system specific.
The last time we discussed this, it was felt that these specialist
utilities (which themselves are part of the LSB) are not targets for LSB
portability in and of themselves. But maybe we were 

Nick Stoughton                          Cell: 510 388 1413
USENIX Standards Liaison                Fax:  510 548 5738

More information about the lsb-discuss mailing list