Bug 12866
| Summary: | [PATCH] RFE for /bin/ls to add a -n option for showing uid/gid numerically | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | pckizer | ||||
| Component: | bin | Assignee: | Sheldon Hearn <sheldonh> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | 3.2-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
pckizer
1999-07-29 07:20:00 UTC
A good reason for implementing this: Try to do an ls -l on a local disk when the NIS server is down. Responsible Changed From-To: freebsd-bugs->sheldonh I'll take this one. There are a couple of nits, so I'll post back a revised patch for your enjoyment. pckizer@nostrum.com wrote: > I am familiar with having a '-n' option to /bin/ls on other platforms I'm very much in favor of adding this option, thank you for taking the time to code it. My one suggestion would be that you optimize the code slightly for the most likely case, namely that the -n option has not been specified. > + if (!f_numbers) { > + user = user_from_uid(sp->st_uid, 0); > + group = group_from_gid(sp->st_gid, 0); > + } else { > + snprintf(user_num, sizeof(user_num), > + "%d", sp->st_uid); > + user = user_num; > + snprintf(group_num, sizeof(group_num), > + "%d", sp->st_gid); > + group = user_num; > + } Hope this helps, Doug On Thu, 29 Jul 1999 18:05:49 EST, Mike Pritchard wrote:
> If NetBSD or OpenBSD implement the -n option, we should probably just
> incorporate their program and man page changes instead of cooking up
> our own.
Both platforms support -n, both in different ways. I'll use their
variable names, no problem. In OpenBSD, -n implies -l, which is stupid.
NetBSD is more sensible.
I only want -n to have an effect when -l is specified, so that I can do
alias ls='ls -n'
When I do ``ls -l'' I'll get long listings with numeric user and group
columns. Otherwise, I'll get short listings as normal.
I'll copy NetBSD. Thanks for the tip.
Ciao,
Sheldon.
>Alright, here's a patch for your perusal. It differs from yours in that: > > * Variables have been renamed. ... I see a few more problems. >RCS file: /home/ncvs/src/bin/ls/ls.c,v >retrieving revision 1.24 >diff -u -d -r1.24 ls.c >--- ls.c 1999/05/08 10:20:30 1.24 >+++ ls.c 1999/07/29 17:32:51 >@@ -100,6 +100,7 @@ > int f_timesort; /* sort by time vice name */ > int f_type; /* add type character for non-regular files */ > int f_whiteout; /* show whiteout entries */ >+int f_numnames; /* show numeric uid and gid in long listing */ Disorder. >@@ -401,6 +405,7 @@ > char *initmax; > int entries, needstats; > char *user, *group, *flags, buf[20]; /* 32 bits == 10 digits */ >+ char uid[10], gid[10]; Disorder. char variables not grouped together. At least the arrays should be. The comment for buf[] applies more directly to the new arrays. You shouldn't assume that uid_t is 32 bits. >@@ -512,10 +517,19 @@ > > btotal += sp->st_blocks; > if (f_longform) { >- user = user_from_uid(sp->st_uid, 0); >+ if (f_numnames) { >+ snprintf(uid, sizeof(uid), "%u", >+ sp->st_uid); >+ user = uid; >+ snprintf(gid, sizeof(gid), "%u", >+ sp->st_gid); >+ group = gid; snprintf() returns a value which is always ignored. It is explicitly (void)ed elsewhere. This is not the way to use snprintf. Either ensure that the buffer is large enough, and don't use snprintf, or size the buffer sloppily and check that it was large enough using snprintf and handle the error somehow. Bruce State Changed From-To: open->suspended Committed to HEAD, MFC should probably be held off until Bruce's concerns are addressed. State Changed From-To: suspended->analyzed The style issues have been addressed. This one's an MFC candidate, once it's had a little time in CURRENT. Just some feedback. I've filed a defect report with the OpenGroup people in which I propose that -n, -g and -o should not imply -l. When we get feedback from them, we'll go with the standard, whatever they decide. Ciao, Sheldon. State Changed From-To: analyzed->closed My Open Group report went nowhere. Since ls(1) is not recommended as a source for reliable input in portable shell scripts, and since our ls(1) already deviates from the standards, I'm closing this PR and leaving the behaviour as is. The documentation aspect of this issue will be addressed when my standards documentation project gets off the ground, probably after BSDcon. |
