Bug 189057 - Adding an option to ls(1) to display file permissions in octal
Summary: Adding an option to ls(1) to display file permissions in octal
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 9.2-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-27 18:50 UTC by A.J. "Fonz" van Werven
Modified: 2024-12-24 16:41 UTC (History)
4 users (show)

See Also:


Attachments
file.diff (5.38 KB, patch)
2014-04-27 18:50 UTC, A.J. "Fonz" van Werven
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description A.J. "Fonz" van Werven 2014-04-27 18:50:00 UTC
A user of the FreeBSD Forums requested that an option be added to /bin/ls that makes the long format (-l option) display the file permissions in octal rather than symbolically, e.g. instead of "-rwxr-xr-x" it would say "-0755". The attached patch does just that and has been proposed on freebsd-hackers@, where it was suggested that a PR be submitted to prevent it from "getting lost".

If the proposed addition has already been incorporated or rejected, this PR can be closed.

Fix: Apply the attached patch. It includes an update to the usage message and to the man page, although the STANDARDS part probably needs some reviewing.

Patch attached with submission follows:
How-To-Repeat: N/A: this is a feature request, not a bug report.
Comment 1 Jilles Tjoelker freebsd_committer freebsd_triage 2015-01-20 19:45:12 UTC
I'm a bit wary of adding additional option letters to ls(1).

A similar effect can be obtained using stat(1). For example,

stat -f '%.1Sp%Mp%Lp %3l %8Su %8Sg %8Z %Sm %N' -t '%b %e %H:%M' PATHNAMES
Comment 2 A.J. "Fonz" van Werven 2015-10-27 09:49:09 UTC
There has been no additional feedback from anyone else, so I figured it's time to move this along (in whatever direction).

Although I agree that ls(1) already has many options, that same argument can easily be bent and shaped the other way around to say: if there are already 256 options, what does one more matter?

And another argument is that, as far as I can see, stat(1)-based and similar one-liners don't work too well with other ls(1) options.

However, I think I might have come up with another solution: how about if I create a port instead? That way everybody wins: the FreeBSD source tree remains blissfully unaffected, yet those who like this feature (it wasn't my idea, but I liked it enough to implement it) can install it from the ports tree.

If it's agreed that creating a port is a better way to go, this bug can be closed as far as I'm concerned.
Comment 3 Chris Hutchinson 2015-11-02 22:25:34 UTC
OK. Just found this pr(1).
I'd like to weigh in on this...
I was the one who started this mess, by making a request in the FreeBSD
forums. As memory serves, I asked if there was any incantation of ls(1)
that would return the OCTAL properties of a file, and directory. The
answer was no.
But, "Fonz" quickly hacked up a quick diff(1)/patch(1) that accomplished
exactly what I had asked about -- Thanks again, Fonz!

That's nice. But what's your point?

Point is; in any event this is a nice option. This can be
considered especially helpful for *NIX new-commers, as it can
be difficult at first to figure out the permissions scheme --
especially those coming from Microsoft products. This "feature"/
option adds precious little *extra* code, and does NOT violate POSIX.
It is more intuitive (for most) to first look to ls(1) for this
type of information, than to look otherwise.
Perhaps better; is there any strongly compelling reason that this
option should *not* be added to ls(1)?

Thank you for your indulgence, and thank you again, Fonz.

--Chris
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2018-05-20 23:54:04 UTC
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"
Comment 5 Chris Hutchinson 2018-07-02 22:54:09 UTC
bump.

anyone?
Comment 6 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:38:57 UTC
Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>