[acqq]

Who never wrote it but assumed we know that the same program in Perl, without using command line switches is

    while (<>) {
        print;
    }

Still Awk is shorter:

     { print }

And if you are allowed change the switches of the command line to Perl for your program that Perl program can have exactly 0 bytes.

[patio11]

Awk is even shorter: anything truthy works. You don't even need the print statement or brackets. Thus there are nine separate 1-byte programs which produce cat: [1], [2], [3], etc etc.

By default, unless you use the BEGIN block or something, awk will run your program on each line of stdlin. This is useful for programs of the type:

(/some regular expression/) { some action}

The default action if you don't specify one is "print $0" (the whole matching line). If your condition is a plain-ol' expression rather than a regular expression, and it always evaluates truthy, you thus get every line.

[acqq]

You are right, the shortest awk is one byte. Please post the link all nine variants I wasn't able to Google it.

Still the shortest Perl is 0 bytes when the command line switch is allowed to be -p

Update: That's actually called "the sed mode of Perl." Moreover these two command lines behave similarly:

    perl -pe 's/search/replace/g'

and

    sed 's/search/replace/'

[dvdkhlng]

SED is shorter (0 byte). SED /is/ a turing complete language [1] so don't try to claim that I'm cheating.

  sed < input > output 

:)

[1] http://robertkotcher.com/sed.html

[update] s/set/sed/

[acqq]

The command line equivalent, with Perl:

    perl -pe '' <input >output

[Alphasite_]

Even java can do that setOut(system.in); (iirc)

[dvdkhlng]

> Even java can do that setOut(system.in);

I was referring to an empty SED-program that would then be run via 'sed -f empty-file.sed'. Of course you need >0 bytes to invoke the SED program.

[RyanZAG]

Sure, but if you want to modify this code to send stdin over the network or through bluetooth in the Java version, you would just replace 'System.out' with the socket. The code would remain the same - in fact the whole class could be reused by having it pass in an input and output stream as parameters.

Your example is very much just a special shortcut for one special condition. It's not generalizable in the same way. And let's be honest - most of today's code is not writing to standard output, it is writing to some iOS or Android GUI or outputting JSON to be used in some javascript webapp. That kind of shortcut just doesn't make sense anymore and is a relic of a different time.

[acqq]

In Linux you can redirect the stdout to the the socket outside of your program, no programming required. You can test and develop everything with stdout and let the same unmodified file run in the web server. See traditional CGI, that's how dynamically generated web pages were easiest to implement long ago:

http://computer.howstuffworks.com/cgi3.htm

The server opens the socket, redirects the stdout to his socket while calling your program fully unmodified.

[RyanZAG]

You open network sockets in Linux and redirect stdout to them? It's possible with curl I guess, but generally people don't do that as it's hard to send the data in the right format. Mostly people will use a tool to access network services.

As for serving files, you'd normally let nginx or apache take care of the sockets for you and not use output redirection.

In Plan9 it's actually viable to use network sockets as files which is pretty nice, but for Linux it's not really how people do it.

[acqq]

> but for Linux it's not really how people do it.

Please explain that to all the people who wrote CGI scripts for years. Seen the link at all?

[RyanZAG]

CGI scripts are dead though. It turns out it wasn't a good way to do it. It's better to use a nice new invention like Apache or Nginx to handle the sockets for you and then use frameworks specifically designed to handle HTTP responses as piping HTML through std inputs is difficult and error prone.

The ability of a language to easily write to std out is simply not important anymore apart from shell scripting which is mostly used these days for setting up the runtime environment and building other languages to handle the grunt work.

I don't know of any companies that still pipe std output directly to sockets anymore, but I guess there must be some. If your company still does this then a language feature like that makes sense. For most people, having the ability to write code that can directly write to sockets without piping through a shell is better practice.

[einhverfr]

I wouldn't say they are totally dead. They are great for relatively quick/dirty code.

The major advantage that CGI gives you is the fact that you get a new, clean process on each request. This means you have fewer and simpler failure cases. This can be helpful when you have a line of business web application though it is certainly suboptimal for public-facing scalable systems.

I wouldn't say cgi is dead. It still has a role to play. It is not the ideal way for doing many things though. I.e. they are no longer the go-to tool, but rather one tool for relatively lower-volume applications where performance matters less than some other considerations.

[blossoms]

That mangles binary data.

    $ printf 'binarydata'|awk '{ print }'|hexdump -C
    00000000  62 69 6e 61 72 79 64 61  74 61 0a                 |binarydata.|
    0000000b

[sadfnjksdf]

grep is even shorter:

    grep $

That reads lines from stdin and echoes to stdout.

[dvdkhlng]

Grep expressions are not a turing-complete language, so I guess that won't count. You could claim that you solved the task using a shell script (that invoked the grep "function") but if you programmed in shell, the shortest solution AFAICS is

  #!/bin/sh
  cat