In D34747#790015, @pauamma_gundo.com wrote:

As disgorged by grep -rH -E 'ls +-[a-zA-A0-9]*o' /usr/src, the following files in src also need changes:
/usr/src/share/skel/dot.shrc:alias ll='ls -laFo'
/usr/src/sys/contrib/zstd/tests/gzip/init.sh: perms=\ls -dgo "$d" 2>/dev/null\ &&
/usr/src/bin/ls/tests/ls_tests.sh: atf_set "descr" "Verify that the output from ls -o prints out the chflag values or '-' if none are set"
/usr/src/bin/ls/tests/ls_tests.sh: -s exit:0 ls -lo a.file
/usr/src/bin/ls/tests/ls_tests.sh: -s exit:0 ls -lo b.file
/usr/src/bin/chflags/chflags.1:You can use "ls -lo" to see the flags of existing files.

Nothing obvious in the ports tree, but that doesn't include actual source code, so I think an exp-run is in order. There's one ls -lo in the handbook (I haven't checked the rest of the doc tree). And of course, that doesn't and can't account for all the unported apps and homegrown ops or devops shell programs out there. With that in mind, I suggest a staged change instead, with introducing -O and adding a deprecation message to -o as the first stage.

Thank you for your help. I edited most of the files, but I cannot find "/usr/src/sys/contrib/zstd/tests/gzip/init.sh".

In D34747#790074, @fel1x.mintchoco.development_gmail.com wrote:

Thank you for your help. I edited most of the files, but I cannot find "/usr/src/sys/contrib/zstd/tests/gzip/init.sh".

Once I checked 14-current source as of 12ish hours ago instead of 12.2 source (I thought i was, but I must have gotten confused), I noticed that file is gone indeed, but I found 2 more:

sys/contrib/openzfs/tests/zfs-tests/tests/functional/acl/off/dosmode.ksh; sys/contrib/openzfs/tests/zfs-tests/tests/functional/acl/off/dosmode.ksh: ls -lo $path | awk '{ gsub(",", "\n", $5); print $5 }' | \
tools/test/stress2/misc/fts2.sh; sprintf(help, "ls -lo %s", p->fts_path);

I'm concerned about changing the interface in a backwards-incompatible manner for something as core as ls but will leave that to others

@emaste @jhb can you please take a look and give the approval from src?

I think this is a bad idea. It's one of the cases where in the past we've made a conscious decision to deviate from POSIX and I see little to no value to our users here. These are little used options there's not a lot of demand for and at the same time, it breaks compatibility with old code. On the whole, I think that situation would suggest we do not want this.

In D34747#898852, @imp wrote:

I think this is a bad idea. It's one of the cases where in the past we've made a conscious decision to deviate from POSIX and I see little to no value to our users here. These are little used options there's not a lot of demand for and at the same time, it breaks compatibility with old code. On the whole, I think that situation would suggest we do not want this.

I don't understand what you mean.

FreeBSD is an Open Source, standards-compliant Unix-like operating system

source: FreeBSD Handbook

If this revision is not accepted because FreeBSD has decided not to follow POSIX, then why do you call it "standards-compliant operating system"?

In D34747#898912, @fel1x.mintchoco.development_gmail.com wrote:

In D34747#898852, @imp wrote:

I think this is a bad idea. It's one of the cases where in the past we've made a conscious decision to deviate from POSIX and I see little to no value to our users here. These are little used options there's not a lot of demand for and at the same time, it breaks compatibility with old code. On the whole, I think that situation would suggest we do not want this.

I don't understand what you mean.

Breaking people's existing scripts (and with a tool as core as ls people will have scripts that invoke and and parse its output) is a cost. The amount of the cost is relative, but in this case it's a widely used tool (ls) and it's a feature that is also used as it has no standard alternative (there is no way in POSIX to list file flags, so any existing scripts fetching file flags via ls are using this). Those both make the cost higher than in other cases of changing behavior.

FreeBSD is an Open Source, standards-compliant Unix-like operating system

source: FreeBSD Handbook

If this revision is not accepted because FreeBSD has decided not to follow POSIX, then why do you call it "standards-compliant operating system"?

Because FreeBSD's usage here (and BSD in general) pre-dates the standard. All of the UNIX-like OS's have extensions to and deviations from POSIX in part because POSIX itself was originally an attempt to harmonize differences between the BSD and SYSV "forks" of UNIX. FWIW, both NetBSD and OpenBSD implement the compromise I was going to suggest which is to implement -g and -n per POSIX, but leave -o as the custom BSD option that lists file flags.

In D34747#900964, @jhb wrote:

Because FreeBSD's usage here (and BSD in general) pre-dates the standard. All of the UNIX-like OS's have extensions to and deviations from POSIX in part because POSIX itself was originally an attempt to harmonize differences between the BSD and SYSV "forks" of UNIX. FWIW, both NetBSD and OpenBSD implement the compromise I was going to suggest which is to implement -g and -n per POSIX, but leave -o as the custom BSD option that lists file flags.

I like the NetBSD/OpenBSD solution. It breaks nothing, increases standards conformance and lets us have one BSD standard for this.

I'd like to also point out that the -o thing likely is keyed off matching either FreeBSD or *BSD in scripts, so people already cope with the varying standards for this.

In D34747#903407, @imp wrote:

In D34747#900964, @jhb wrote:

Because FreeBSD's usage here (and BSD in general) pre-dates the standard. All of the UNIX-like OS's have extensions to and deviations from POSIX in part because POSIX itself was originally an attempt to harmonize differences between the BSD and SYSV "forks" of UNIX. FWIW, both NetBSD and OpenBSD implement the compromise I was going to suggest which is to implement -g and -n per POSIX, but leave -o as the custom BSD option that lists file flags.

I like the NetBSD/OpenBSD solution. It breaks nothing, increases standards conformance and lets us have one BSD standard for this.

I'd like to also point out that the -o thing likely is keyed off matching either FreeBSD or *BSD in scripts, so people already cope with the varying standards for this.

I want to try this:

# if __POSIX_VISIBLE >= 200809

Can this macro work in this situation?

In D34747#910651, @fel1x.mintchoco.development_gmail.com wrote:

In D34747#903407, @imp wrote:

In D34747#900964, @jhb wrote:

Because FreeBSD's usage here (and BSD in general) pre-dates the standard. All of the UNIX-like OS's have extensions to and deviations from POSIX in part because POSIX itself was originally an attempt to harmonize differences between the BSD and SYSV "forks" of UNIX. FWIW, both NetBSD and OpenBSD implement the compromise I was going to suggest which is to implement -g and -n per POSIX, but leave -o as the custom BSD option that lists file flags.

I like the NetBSD/OpenBSD solution. It breaks nothing, increases standards conformance and lets us have one BSD standard for this.

I'd like to also point out that the -o thing likely is keyed off matching either FreeBSD or *BSD in scripts, so people already cope with the varying standards for this.

I want to try this:

# if __POSIX_VISIBLE >= 200809

Can this macro work in this situation?

No, for multiple reasons.

In D34747#910651, @fel1x.mintchoco.development_gmail.com wrote:

In D34747#903407, @imp wrote:

In D34747#900964, @jhb wrote:

Because FreeBSD's usage here (and BSD in general) pre-dates the standard. All of the UNIX-like OS's have extensions to and deviations from POSIX in part because POSIX itself was originally an attempt to harmonize differences between the BSD and SYSV "forks" of UNIX. FWIW, both NetBSD and OpenBSD implement the compromise I was going to suggest which is to implement -g and -n per POSIX, but leave -o as the custom BSD option that lists file flags.

I like the NetBSD/OpenBSD solution. It breaks nothing, increases standards conformance and lets us have one BSD standard for this.

I'd like to also point out that the -o thing likely is keyed off matching either FreeBSD or *BSD in scripts, so people already cope with the varying standards for this.

I want to try this:

# if __POSIX_VISIBLE >= 200809

Can this macro work in this situation?

That only controls what posix C functions are visible. It is not a conformance level relating to how commands work. Also, even if it were the consensus of the review is that the incompatible change is a hard no.

In D34747#910653, @imp wrote:

In D34747#910651, @fel1x.mintchoco.development_gmail.com wrote:

In D34747#903407, @imp wrote:

In D34747#900964, @jhb wrote:

Because FreeBSD's usage here (and BSD in general) pre-dates the standard. All of the UNIX-like OS's have extensions to and deviations from POSIX in part because POSIX itself was originally an attempt to harmonize differences between the BSD and SYSV "forks" of UNIX. FWIW, both NetBSD and OpenBSD implement the compromise I was going to suggest which is to implement -g and -n per POSIX, but leave -o as the custom BSD option that lists file flags.

I like the NetBSD/OpenBSD solution. It breaks nothing, increases standards conformance and lets us have one BSD standard for this.

I'd like to also point out that the -o thing likely is keyed off matching either FreeBSD or *BSD in scripts, so people already cope with the varying standards for this.

I want to try this:

# if __POSIX_VISIBLE >= 200809

Can this macro work in this situation?

That only controls what posix C functions are visible. It is not a conformance level relating to how commands work. Also, even if it were the consensus of the review is that the incompatible change is a hard no.

Okay, I will work on reverting -o option and update diff file.

Can you confirm your author details, my guess is "Minsoo Choo <fel1x.mintchoco.development@gmail.com>"?

In D34747#934900, @jhb wrote:

Can you confirm your author details, my guess is "Minsoo Choo <fel1x.mintchoco.development@gmail.com>"?

Hi,

I'm switched my email address to minsoochoo0122@proton.me.

Ah, this adds at least one test failure for -g which I will fix before pushing.