[HN Gopher] You can do a lot with an empty file
       ___________________________________________________________________
        
       You can do a lot with an empty file
        
       Author : picture
       Score  : 73 points
       Date   : 2022-04-06 19:16 UTC (3 hours ago)
        
 (HTM) web link (rachelbythebay.com)
 (TXT) w3m dump (rachelbythebay.com)
        
       | geocrasher wrote:
       | This is a great trick for a _lot_ of things. For example, if a
       | web server is getting lots of attacks against a particular URL,
       | one could block that URL or otherwise make it inaccessible. That
       | 'll turn it into a 404 or 500, or whatever. But it turns out that
       | a 200 is much faster, and so replacing the target with a blank
       | file is faster than denying it. This is particularly true with
       | xml-rpc.php. Instead of just removing it, empty it. Problem
       | solved.
        
       | yakubin wrote:
       | _> Does this mean the smallest  /bin/true is actually an empty
       | file?_
       | 
       | That was exactly the implementation of _/ bin/true_ in Unix v7:
       | <https://github.com/v7unix/v7unix/blob/master/v7/bin/true>
        
       | nonrandomstring wrote:
       | AFAICS some other interpreters, perl, python, ruby, tcl are happy
       | to return a 0 exit code if invoked on an empty file.
        
         | remram wrote:
         | Empty files are common in Python: a __init__.py is required (or
         | was) to mark a directory as a Python package, allowing its
         | content to be imported.
        
         | kayodelycaon wrote:
         | Pretty much. They ran all the code that was in the file without
         | errors.
        
       | emerged wrote:
       | I ran into this lately when I hadn't validated a successful file
       | transfer. The script ran to completion against all expectations.
       | Obviously you should check a hash before executing a download
       | anyway, but this was just some automated build code.
        
       | ndotl wrote:
       | You can even win an IOCCC and be remembered nearly thirty years
       | later: https://github.com/c00kiemon5ter/ioccc-obfuscated-c-
       | contest/...
        
       | gnarula wrote:
       | In case anyone's curious, in absence of a shebang (#!), Linux [1]
       | returns an ENOEXEC to the execve syscall, after which the
       | invoking program (the shell) handles the failure. Usually shells
       | default to running the file as a shell script with itself as
       | argv0.
       | 
       | [1]
       | https://github.com/torvalds/linux/blob/3e732ebf7316ac83e8562...
        
         | nerdponx wrote:
         | Was this behavior inherited from Unixes past? It seems like
         | it'd be better if shells just returned the error back to the
         | user.
        
           | fuzzybear3965 wrote:
           | Shells return exit codes, not typed error values. What kind
           | of output would you expect from the shell, exactly?
        
             | deathanatos wrote:
             | I'd expect the same as any other failure from execv(2).
             | Something like,                 zsh: Exec format error:
             | empty-file       (last command returned 127.)
             | 
             | (127 is the exit status for other failures, so I've used it
             | here. The second line is intended to be part of my PS1, the
             | first zsh's normal reporting. The string used here is what
             | I get from perror() for that code.)
        
             | nerdponx wrote:
             | Status 129 or something else outside the usual range, plus
             | a message that the file was not a valid ELF and also has no
             | shebang, therefore cannot be executed.
        
       | wyldfire wrote:
       | > as far as the package database was concerned, it was
       | 
       | "rpm -qV" is a command that will audit the signatures of a
       | package's contents. I don't know if dpkg has something similar
       | but it would be cool if it did.
        
         | acranox wrote:
         | debsums
         | https://manpages.ubuntu.com/manpages/jammy/en/man1/debsums.1...
        
           | wyldfire wrote:
           | md5? Is 'jammy' a remarkably old platform? I hope so.
           | 
           | But regardless of the signature algorithm, thanks for sharing
           | the mechanism.
        
       | mcphage wrote:
       | This reminds me of the story about the "go.com" program someone
       | sold for PS5, which was just an empty file:
       | http://peetm.com/blog/?p=55
        
         | skrtskrt wrote:
         | this is fantastic
        
         | dylan604 wrote:
         | It's probably the cleanest code you will ever see.
        
           | _kst_ wrote:
           | And it probably had at least one bug.
        
       | Wowfunhappy wrote:
       | > Yesterday's post about "pipefail" also involved some systems
       | which treated an empty file as a valid file. This turns out to be
       | surprisingly common.
       | 
       | I don't understand why this is surprising. Of course an empty
       | file is a valid file, just like an empty piece of paper is a
       | valid piece of paper.
       | 
       | I mean, yes, a piece of paper is also different. Paper is a
       | physical object with volume and weight; a file is a sequence of
       | bytes representing some information. But, step out of your
       | programmer mindset for a moment. Almost every user interface
       | represents files as objects containing information, not
       | information itself.
        
       ___________________________________________________________________
       (page generated 2022-04-06 23:00 UTC)