3

I found what I think is a bug in the command chown in OS X 11.6. It appears to work contrary to its man page, ignoring the -f flag.

T_MaceT 33 ) chown -f T_MaceT foo
chown: foo: No such file or directory
T_MaceT 34 ) echo $?
1

According to the man page, using -f, it should ignore that the file doesn't exist nor should it change the return-value. (I have tested the correct behavior on RedHat 6 for comparison.)

I'm not sure who (if anyone) would fix these kinds of bugs. The man page refers to BSD. Is there an active project supporting these kinds of things?

  • 1
    @macetw, You said, "According to the man page, using -f, it should ignore that the file doesn't exist nor should it change the return-value." and that is not at all what the man page for chown under macOS states! – user3439894 Apr 18 '17 at 3:55
  • 1
    The f option is an extension of the POSIX Standard and should not be considered portable. – fd0 Apr 18 '17 at 9:14
  • Perceptions are different. As a long-time Linux user, I expect that "-f" is the standard way to "force the action to be done and don't complain to me about it." This behavior is true (in Linux) about "rm," "mv," "cp," and so on. Specifically with "rm," I do this all the time, that the file might not exist. My question from the title is still open: If I want to improve the command-shell experience in Mac, where do I document my bug/suggestion ? – macetw Apr 18 '17 at 16:57
  • 1
    Your question is answered in the comments on the answer below. Recently I thought of your complaint when I experienced a similar design "issue" (not to say "bug"): I was switching between applications, and a keyboard shortcut corresponded to different commands in each app. This was frustrating at first, but the easiest solution was to learn the relevant keyboard shortcuts in each app. If identical behavior is not specified in a common standard such as POSIX, it can't be expected, as @fd0 said. – Big Mac May 4 '17 at 18:02
5

It's not a bug, it's poorly written documentation. The -f option for chown states:

Don't report any failure to change file owner or group, nor modify the exit status to reflect such failures.

This means the -f option is only applicable if the target file exists and there was an error in changing the owner or group of the file, which of course you can't do on a nonexistent file as in the OP example under macOS.

To show that the -f option actually works as intended, use the following compound command in Terminal while not doing so as root or using sudo:

touch ${TMPDIR}testfile; chown root ${TMPDIR}testfile; echo $?; rm ${TMPDIR}testfile

The output will be, e.g.:

chown: /var/folders/7l/lcvbc47n3sd7jcztdhc9c_pw0000gn/T/testfile: Operation not permitted
1

In this first form, without the -f option it fails, exits >0, because the chown command is trying to set the owner of ${TMPDIR}testfile to root while being executed not as root and not using sudo.

Now execute with the -f option:

touch ${TMPDIR}testfile; chown -f root ${TMPDIR}testfile; echo $?; rm ${TMPDIR}testfile

The output will be:

0

In this second form, with the -f option, it succeeds, exits with 0 without having made any change, because it was done not as root and not using sudo, which is necessary to change the owner of a file to root.


Note that each OSes chown is not equal in all functionality to each other. In other words, while I don't have Red Hat, as mentioned in the OP, I do have Linux Mint to compare to, and the man page in Linux Mint -f option for chown states:

suppress most error messages

As you see most is the keyword, so it doesn't suppress all error messages in Linux Mint nor is the description of what -f does with chown under Linux Mint as detailed and explicit as under macOS.

So while in Linux Mint, not as root or using sudo, chown -f root non_existant_filename will not output an error, however, its exit code is 1, not 0 as it is with the macOS chown example above using -f within its defined context.

  • 1
    Perceptions are different. As a long-time Linux user, I expect that "-f" is the standard way to "force the action to be done and don't complain to me about it." This behavior is true (in Linux) about "rm," "mv," "cp," and so on. Specifically with "rm," I do this all the time, that the file might not exist. My question from the title is still open: If I want to improve the command-shell experience in Mac, where do I document my bug/suggestion ? – macetw Apr 18 '17 at 16:46
  • @macetw This answer convincingly argues that it is not a bug. Your counterargument seems to concede that it is not a bug, so perhaps you should change the word "bug" in the question to something like "design flaw"—in which case you are looking for a place to discuss the design rationale of various features? For info on bug reporting, see, e.g., developer.apple.com/bug-reporting and freebsd.org/support/bugreports.html – Big Mac Apr 18 '17 at 17:50
  • @macetw, I too am a long-time Linux user however the fact that we're long-time Linux users is totally irrelevant because macOS is not Linux and as already stated the -f option is not equal between OS platforms and or versions of chown. I believe my test confirms it works as intended under macOS. That said, there are others ways to code to avoid unwanted output. I'll assume your scripting something in which you want only clean output displayed, as the -f option is not really needed with a single one time command issued on the command line. Continued in next comment. – user3439894 Apr 18 '17 at 17:57
  • 2
    @macetw, So, in a script, e.g. chown root nonexistant_filename 2>/dev/null will hide the chown: nonexistant_filename: No such file or directory error output. Also in scripts there are easy ways to confirm the file exists before attempting to act upon it (and probably should be done so in many cases). That said, if you really want to pursue this as a bug and or design flaw then the comment made above by Big Mac containts some links to facilitate that. – user3439894 Apr 18 '17 at 17:57
  • 2
    @macetw Have a look at opensource.apple.com/source/file_cmds/file_cmds-264.50.1/chown/…: The fts functions are used to traverse the file hierarchy, failure to stat a file will result in a warning being displayed (search for FTS_ERR). So the behavior is definitively intentional. One might argue that it is not consistent with cp, mv etc, but then a lot of Unix binaries ain't (awk for instance uses -f to pass a script file). – nohillside Apr 18 '17 at 19:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .