Hacker News

You can see it in the code, lstat vs stat and copy_special, copy_fifo vs copy_file. They're all in utils.c.

from the lstat man page:

     The lstat() function is identical to stat() except when the named file is
     a symbolic link, in which case lstat() returns information about the link
     itself, not the file the link references.

    $ tree test1
    test1
    |-- file.txt
    `-- link.txt -> ../link.txt

    0 directory, 2 files

    $ cp -r test1 test2
    $ tree test2
    test2
    |-- file.txt
    `-- link.txt

    0 directory, 2 files

    $ cp -R test1 test3
    $ tree test3
    test3
    |-- file.txt
    `-- link.txt -> ../link.txt

    0 directory, 2 files

    $ cp -RL test1 test4
    $ tree test4/
    test4/
    |-- file.txt
    `-- link.txt

    0 directory, 2 files

> links to the source code but never actually says what it is.

The snippet of code makes it very clear what the difference is, no?

flag_copy_as_regular = 1 VS flag_copy_as_regular = 0, where regular would be a "regular" and not "special" file.

Hey, I perfectly understand if not. But do you have the sources that were used to build those binaries?

The oldest version on the GNU ftp server is fileutils-3.13 [1]. I vaguely remember having some links to older versions, probably somewhere in my archived mail. But I don't remember if it was fileutils-3.9 or earlier.

I co-maintain GNU coreutils, so I am interested in reading them. If you have them, you can email me privately or on the public mailing list. Both are listed on the homepage [2].

[1] https://ftp.gnu.org/old-gnu/fileutils/ [2] https://www.gnu.org/software/coreutils/

You should have run that command as the `nobody` user.

I think there is a class of programs where globals are not so terrible. In particular, one-shot programs that do a task and then exit (like `ls`, `cp`, etc).

You may also notice that some of these utilities will allocate memory, then never free it. They just let the OS handle that on program shutdown. That is also generally not recommended in arbitrary code. But again, it's fine for a one-and-done sort of program.

For these cases, the whole program is essentially one function call, and the global namespace is essentially the "body" of that function (hand waving a bit).

It's all a bit subjective, of course (:

This is rather missing the point. The headlined article isn't really about how to achieve a goal, but about the weird history and evolution of a tool that leads us to the rather odd situation that we are in today. And it's far from being the only tool that has a weird history, that looks rather nutty if one looks at it from the point of view of a novice having to learn this stuff.

It's also not even completely covering the weird case of -r and -R for the cp command. On HP-UX, for example, the twain were different, but not in the way that they were in old GNU Core Utilities. That would be too easy. (-:

The AIX manual for cp explains its difference between -r and -R:

* https://ibm.com/docs/en/aix/7.1.0?topic=c-cp-command

Illumos also treats the two differently, but in a subtly different way:

* https://illumos.org/man/1/cp

old cp didn't have `-a`

Anyway, just use rsync.

Thirteen years ago I asked the same question:

https://unix.stackexchange.com/questions/82485/when-wouldnt-...

It seems that recursive by default would have been much more intuitive.

ditto is an option on macOS for copying files and directories [1].

[1]: https://keith.github.io/xcode-man-pages/ditto.1.html

It's also the only option shown in the -h output and in man pages for some versions of cp.

I didn't even know -r was a thing until today.

its trained to read both tekst and code which is enough to know the difference.

appearently i am not :') never knew there was -r

As in the Pokémon, not the Philippines telecom company.

Huh, TIL. In German, "dito" is the correct spelling, so I always figured it would be the same in English as well.

The worst is when things behave different when you give them `~/somedir` vs `~/somedir/`. I think it's rsync that does that

How about port that is lowercase in ssh and uppercase in scp?

I never bothered to learn -C, instead I use:

    tar -cf - . | (cd <dest>;  tar -xf -)

with a sandwiched `| pv |` for fun stats

Double dash long options are basically a GNU extension. BSD utilities generally don't support them. Apparently macOS does not either (since it's based off of FreeBSD)

There are implementations of cp out in the wild that do not recognise the --recursive flag. OpenBSD was mentioned in the article and there’s also busybox cp https://busybox.net/downloads/BusyBox.html

I believe that -R is the safe works-as-expected-everywhere option.

In my minimal attempts to use rsync, I always find examples where they always use a ton of flags alongside the locations. I'm not gonna learn those flags if cp can do it intuitively and with minimal extra commands. Maybe it's just me.

rsync unfortunately doesn't do relinking at all, so I can't use it as a generic replacement for cp.