6 ms·

Just for fun: GNU true.c: https://github.com/coreutils/coreutils/blob/master/src/true.c https://github.com/coreutils/coreutils/blob/master/src/true.... OpenBS

• glandium 9y ago
  FWIW, GNU true.c is that way because the GNU policy is for programs to all have --help and --version arguments. Other fun fact, in some UNIXes, true looked(looks?) like: #!/bin/sh # Some multiple line copyright notice from AT&T Yup, that's a shell script with only comments, all of which are a copyright notice for what is, essentially, an empty file. I saw that on Solaris something like 15 years ago. I'm sure it made its way to other flavors of UNIX.
  • kibwen 9y ago
    Now you've got me wondering what it would mean to try and enforce the copyright on an empty file. You'd think there would be some prior art, right? :)
    • perl4ever 9y ago
      Empty files remind me of an episode where I worked. We were supposed to provide a set of files for a court case. But there was a missing zero byte file due to a glitch in processing. So just create one, right? NOPE. The client insisted we find and copy the original empty file from the original media.
      • taneq 9y ago
        You just know it's because, if you just made a new zero-byte file, the opposition in the case would claim that you forged the file and that the evidence was then tainted. Stupid, but your goal here isn't to reproduce the file, it's to stop a stupid argument from convincing stupid people to make a stupid decision.
        • fludlight 9y ago
          > your goal...[is] to stop a stupid argument from convincing stupid people to make a stupid decision. This is the best explanation of legal practice I have ever seen.
        • mort96 9y ago
          But... to be sent, the file is recreated a bunch of times right? Because a computer only ever copies, and never “moves”, right? How can it then possibly matter whether the 0b file was recreated by a computer from the instruction of copying the file (which then just turns into an instruction to create the file), or if it was created directly through instructing the computer to create the file? Gah, something something colored bits. http://ansuz.sooke.bc.ca/entry/23 http://ansuz.sooke.bc.ca/entry/23
          • randallsquared 9y ago
            Computers do "move" files, in some cases, by updating the entry in the filesystem registry. In such a case, it might be that no change was made to the file on disk, so no copy was made at all.
            • mort96 9y ago
              I interpreted "provide a set of files for a court case" as some form of sending it either through the Internet or to some portable storage media. He also said "The client insisted we find and copy the original empty file from the original media", which also indicates that. I therefore intended "move" to mean "move from one storage media/computer to another". You're of course correct that if you "move" a file on one file system, the bits won't actually be copied (or moved) anywhere.
              • randallsquared 9y ago
                Sure, no argument. I was responding only to the "computer only ever copies" statement. Sometimes it's hard to know how literal someone is being. :)
      • astrodust 9y ago
        It's like homeopathic copying: A zero byte string can contain trace amounts of the original.
      • jl6 9y ago
        Not a wholly insane request if they were interested in the file metadata as much as the file data.
        • perl4ever 9y ago
          You might think, but metadata travels separately from the actual file, so that wasn't a factor.
          • coldtea 9y ago
            Depending on how it's copied, they can be preserved.
      • TeMPOraL 9y ago
        You wanted to provide a zero-byte file of the wrong colour. Unlike in physical reality, in legal world it strongly matters what colors are your bits (or in this case, what color is the lack of them). http://ansuz.sooke.bc.ca/entry/23 http://ansuz.sooke.bc.ca/entry/23
      • xelxebar 9y ago
        Well, I can see the point of leaving a trail that shows you aren't fraudulently claiming the file is zero bytes. Otherwise, it's just your word.
        • nucleardog 9y ago
          Yeah, if they didn't find a copy on the backup/original media to confirm it's zero bytes, then really all they've provided is their assumption that it's zero bytes. I'm no lawyer, but the testimony of the IT guy (and associated reasoning/etc) seems like a totally different kind of evidence than a true and accurate copy of a file from an original medium. And having the IT guy testifying seems like way more of a pain than just making him find the file.
    • robinhouston 9y ago
      There’s a lovely story[1] from the early days of personal computing: “GO.COM contained no program bytes at all – it was entirely empty. However, because GO.COM was empty, but still a valid program file as far as CP/M was concerned (it had a directory entry and file-name ending with .com), the CP/M loader, the part of the OS whose job it is to pull programs off disk and slap them into the TPA, would still load it! So, how does this help? Well, using the scenario above: • the user exited WordStar • the user ran DIR (or whatever else they needed) and at some future point would be ready to re-run Wordstar • the user now ‘loaded’ and ran GO.COM • the loader would load zero bytes of the GO.COM program off disk into the TPA – starting at address 0100h – and then jump to 0100h – to run the program it just loaded [GO.COM]! • result – it simply re-ran whatever was in the TPA when the user last exited to DOS – instantly [WordStar in this example]! So, GO.COM, which consisted of zero bytes of code – and sold for £5 a copy is, I figure, the most profitable program ever written (as any other program will return mathematically fewer £s per byte than GO.COM did)!” 1. http://web.archive.org/web/20160304014157/http://peetm.com/blog/?p=55 http://web.archive.org/web/20160304014157/http://peetm.com/b...
      • exikyut 9y ago
        Thanks! I remember reading about this a while back, but lost the link.
    • matt4077 9y ago
      "prior art" is a term concerning patents, whereas this is copyright. There needs to be a certain level of creative work to qualify for copyright, and an empty program that does nothing is rather unlikely to qualify. The definite case on that subject must be John Cage's "4:33", which is 4 minutes and 33 seconds of silence. Its copyright has been upheld in court. Yes, the estate of John Cage sued somebody who "quoted" to much of his work of silence. That sounds somewhat silly, yet it's well-reasoned: the infringing artist actually acknowledged Cage in the CD inset. And 4'33 isn't really only silence. Audio recordings feature the pianist sitting down, open and closing the piano cover, and the audience making various noises. It's somewhat "out there" obviously, but just the fact that it's rather well-known kind of shows that it did what it was supposed to do.
  • ckuehl 9y ago
    There are some amusing notes about the /bin/true copyright claim here: http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html
    • kibwen 9y ago
      "Note also the claim that there is no warranty, which in this case presumably means that if the program actually does something, you can't sue them." I love this.
• noobermin 9y ago
  That comment on the bsd one from theo is rather funny.
• wahern 9y ago
  I'm surprised that neither GNU yes nor GNU cat uses splice(2). Here's what I get. Note that ./rust is the final Rust program from the article modified to print stats and exit after a set byte count[1], ./splice is a simple C program that uses splice to copy the input string from a generated anonymous temporary file to stdout, and ./consume uses splice to move data from stdin to /dev/null. In all tests the default string of "y\n" is used. $ ./rust | cat >/dev/null 5.220 GB/s (8589934592 bytes in 1.645 seconds) $ ./splice | cat >/dev/null 14.514 GB/s (8589934592 bytes in 0.551 seconds) $ ./rust | ./consume 9.312 GB/s (8589934592 bytes in 0.922 seconds) $ ./splice | ./consume 25.118 GB/s (8589934592 bytes in 0.318 seconds) As you can see, cat(1) is the real bottleneck. splice is Linux-only. Most systems have sendfile(2), including Linux, but I didn't test it. The implementation and semantics of sendfile vary across platforms. [1] I did this before I wrote ./consume (which takes an optional byte count limit), having assumed that GNU cat was using splice. As cat doesn't have a way to limit the number of bytes read/written, and other tools like head or tail definitely don't use splice, the simplest way to limit the benchmark without introducing a bottleneck was to have the producers themselves print stats and exit. The relevant diff is + let mut count = 0u64 as usize; + let bytes = (1u64 << 33) as usize; ... -while locked.write_all(filled).is_ok() {} +while locked.write_all(filled).is_ok() { + count += filled.len(); + if count >= bytes { + break; + } +}
  • Y_Y 9y ago
    Forgive me if I'm missing something subtle, but aren't the first two examples Useless Use Of Cat?
    • isatty 9y ago
      Yes they are. Why not just send it straight to /dev/null?
      • wahern 9y ago
        1) Because splice(2) requires either the source or sink to be a pipe. The source is a regular file so the sink has to be a pipe. 2) Because the example Rust program(s), emulating yes(1), had no [simple] way to measure throughput except by piping to another program. We can't fairly compare program A that writes directly to /dev/null with program B that writes to a pipe even if program A can measure its throughput. 2a) What jwilk said. 3) For some reason I thought that glibc had optimizations to elide fwrites to /dev/null, and some of my code was using stdio (e.g. for the final trailing bytes less than the pagesize). I could've sworn either glibc or bash did this, but I can't find any mention of it, now. I realize it would be crazy difficult and ugly for glibc to do this (because of dup2, etc), but glibc does alot of crazy things, and in any event I didn't bother checking beforehand. Mostly it comes down to fairly comparing benchmarks and kernel facilities. Otherwise, yes, those would be classic examples of Useless Use of Cat.
• halfelf 9y ago
  Once read similar things before, on reddit: https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/?st=j8o227ok&sh=68fba939 https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...
• sgt 9y ago
  On my Mac I'm getting $ yes | pv -r > /dev/null [34.9MiB/s]
• aleden 9y ago
  hmm going in the direction of [binary] instead of [shell script], why not just go further and ditch the whole C stdlib by passing -ffreestanding and then compiling void _start(void) { exit(0); }