cp: -r or -R?

(movq.de)

35 points | by zdw 2 days ago

9 comments

  • bariumbitmap 21 minutes ago
    This blog post is odd because it keeps on hinting about a difference between `-r' and `-R' and links to the source code but never actually says what it is. I'll quote the OpenBSD manual that the post mentions but does not link to for some reason:

    > Historic versions of the cp utility had an -r option. This implementation supports that option; however, its use is strongly discouraged, as it does not correctly copy special files, symbolic links or FIFOs.

    https://man.openbsd.org/cp

  • mkl 33 minutes ago
    -a

    Not sure why you wouldn't want to preserve timestamps, links, etc. by default.

    • JdeBP 8 minutes ago
      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

  • bdavbdav 5 minutes ago
    This always get me. I instinctively -r, until chown which of course doesn’t take it.
  • drhagen 42 minutes ago
    It always seemed like the recursive flag of cp was an implementation detail leaking into the UI. Like, I get that copying a file requires creating more than one inode, but...so? Eventually, graphical OSes agree with me—copy/paste works the same on folders as it does on files.
  • pasc1878 29 minutes ago
    Use rsync instead
    • 5555watch 1 minute ago
      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.
    • trucks-refinish 25 minutes ago
      rsync unfortunately doesn't do relinking at all, so I can't use it as a generic replacement for cp.
  • bsoqk 1 hour ago
    It's "ditto", not "dito"
    • Waterluvian 1 hour ago
      As in the Pokémon, not the Philippines telecom company.
      • Yaqub_W 42 minutes ago
        Much easier to press a key twice than to hunt for é for most people. I get your point though
        • Waterluvian 5 minutes ago
          Apparently Pokémon is in my phone’s word book.
  • 5555watch 35 minutes ago
    On a somewhat related note, I really hate that in scp -r and -R mean entirely different things.
    • pluc 18 minutes ago
      The worst is when things behave different when you give them `~/somedir` vs `~/somedir/`. I think it's rsync that does that
      • amelius 14 minutes ago
        Yes, into versus onto. Luckily we have AI to write our command lines.
    • aulin 28 minutes ago
      How about port that is lowercase in ssh and uppercase in scp?
  • mqus 1 hour ago
    would you be safe in using --recursive always? (e.g. shell scripts)
    • olowe 59 minutes ago
      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
    • hnfong 44 minutes ago
      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)
      • JdeBP 30 minutes ago
        macOS was based off NeXTSTEP, not FreeBSD.

        And the received wisdom about long options in the BSDs is a quarter of a century out of date. When the BSDs gained a getopt_long() in their C libraries thanks to Klausner and Baron, long options quietly started appearing. This process has been gradually and quietly on-going for the whole of the 21st century.

        • throw0101a 13 minutes ago
          > macOS was based off NextBSD, not FreeBSD.

          "NextBSD" was first released in 2015:

          * https://en.wikipedia.org/wiki/NextBSD

          Over a decade after macOS/Mac OS X was initially released:

          > macOS (previously OS X and originally Mac OS X) is a proprietary Unix[7][8] operating system, derived from OPENSTEP for Mach and FreeBSD, which has been marketed and developed by Apple since 2001.

          * https://en.wikipedia.org/wiki/MacOS

          > Darwin is the core Unix-like operating system of macOS, iOS, watchOS, tvOS, iPadOS, audioOS, visionOS, and bridgeOS. It previously existed as an independent open-source operating system, first released by Apple in 2000. It is composed of code derived from NeXTSTEP, FreeBSD[3] and other BSD operating systems,[7] Mach, and […]

          * https://en.wikipedia.org/wiki/Darwin_(operating_system)

          I remember reading release notes for FreeBSD in the '00s and seeing the exact same lines in the release notes for earlier versions of OS X.

          • JdeBP 3 minutes ago
            Bah! Thought NeXTSTEP. Typed NextBSD. Fixed. I've been typing lots of names ending in 'BSD' today. (-:
    • dotancohen 18 minutes ago
      I believe that -R is the safe works-as-expected-everywhere option.
  • here_to_learn 55 minutes ago
    [dead]