Live data from Hacker News

Copying stdin to stdout in Java

gist.github.com

21–30 of 61 posts

Re: Copying stdin to stdout in Java

#21

I don't know much Java. Does 'System.in.read(buffer)' block until stdin is at EOF or buffer is full? Then this solution would be somewhat broken. Imagine a low-bandwidth source on stdin and a audio player connected to stdout, like wget -O - http://audiostream | java inout.java | mplayer /dev/stdin If I had to write this in C I'd use file descriptors in non-blocking mode and select(). With Tcl one could use event-base…

The documentation [1] does not mention any buffering unfortunately. In a quick test on the console it showed line-buffering behavior, so it probably depends on the input file type?

[1] http://docs.oracle.com/javase/7/docs/api/java/io/InputStream...

Re: Copying stdin to stdout in Java

#22
post #16
post #8

Earlier quoted context omitted.

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…

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/'

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

  sed  output 
:)

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

[update] s/set/sed/

Re: Copying stdin to stdout in Java

#23
post #20

I don't know much Java. Does 'System.in.read(buffer)' block until stdin is at EOF or buffer is full? Then this solution would be somewhat broken. Imagine a low-bandwidth source on stdin and a audio player connected to stdout, like wget -O - http://audiostream | java inout.java | mplayer /dev/stdin If I had to write this in C I'd use file descriptors in non-blocking mode and select(). With Tcl one could use event-base…

Using non-blocking mode may be better, but to answer your question: yes, it does block [1]. [1] http://docs.oracle.com/javase/7/docs/api/java/io/InputStream...

(You referenced the one byte read function, instead of the multi-byte function used in the OP.)

The documentation does not answer how long it blocks. Blocking when there is no input is completely ok in this use case as there is nothing better to do instead of waiting for input. The relevant question is how long it blocks after there is some input available for efficiency reasons.

Re: Copying stdin to stdout in Java

#24

I don't know much Java. Does 'System.in.read(buffer)' block until stdin is at EOF or buffer is full? Then this solution would be somewhat broken. Imagine a low-bandwidth source on stdin and a audio player connected to stdout, like wget -O - http://audiostream | java inout.java | mplayer /dev/stdin If I had to write this in C I'd use file descriptors in non-blocking mode and select(). With Tcl one could use event-base…

Not knowing the exact details of used classes, the bigger question is if the exceptions in the OP code can be thrown and if some try catch is needed. In Java the classes like to throw a lot.

Re: Copying stdin to stdout in Java

#25
As he notes in the comments, you'd really just do this:

IOUtils.copy(System.in, System.out);

using the Apache Commons library.

That's the most apples-to-apples comparison to more "scripty" languages that have more stuff built in. With Java you pick the libraries/frameworks you want to use. Commons and Guava are extremely popular and robust libraries and really should be included in any comparison against "real world" Java.

I actually like how in Java you can get down closer to the metal and control the exact buffer size if you want to, or handle all the exception cases instead of just passing them up if you want to. If you're comparing intentionally lower-level more verbose Java code to higher-level Python or whatever, that's not really apples-to-apples. High-level Java involves frameworks.

Re: Copying stdin to stdout in Java

#26
post #19
post #17

Earlier quoted context omitted.

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 whil…

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 fi…

> 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?

Re: Copying stdin to stdout in Java

#27
post #20

Earlier quoted context omitted.

Using non-blocking mode may be better, but to answer your question: yes, it does block [1]. [1] http://docs.oracle.com/javase/7/docs/api/java/io/InputStream...

(You referenced the one byte read function, instead of the multi-byte function used in the OP.) The documentation does not answer how long it blocks. Blocking when there is no input is completely ok in this use case as there is nothing better to do instead of waiting for input. The relevant question is how long it blocks after there is some input available for efficiency reasons.

> there is nothing better to do instead of waiting for input.

In case no more input is available it would be best to already output the data that have accumulated in buffer. Else in case the input program deadlocks you're never going to see the last (up to 8191) bytes output.

This is what non-blocking I/O is for. With non-blocking I/O you first wait until your input channel becomes readable, then reading functions return as soon as the data available for read is exhausted.

Re: Copying stdin to stdout in Java

#28
post #16

Earlier quoted context omitted.

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/'

SED is shorter (0 byte). SED /is/ a turing complete language [1] so don't try to claim that I'm cheating. sed output :) [1] http://robertkotcher.com/sed.html [update] s/set/sed/

[deleted]

Re: Copying stdin to stdout in Java

#29
post #16

Earlier quoted context omitted.

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/'

SED is shorter (0 byte). SED /is/ a turing complete language [1] so don't try to claim that I'm cheating. sed output :) [1] http://robertkotcher.com/sed.html [update] s/set/sed/

The command line equivalent, with Perl:

    perl -pe '' output

Re: Copying stdin to stdout in Java

#30
post #25

As he notes in the comments, you'd really just do this: IOUtils.copy(System.in, System.out); using the Apache Commons library. That's the most apples-to-apples comparison to more "scripty" languages that have more stuff built in. With Java you pick the libraries/frameworks you want to use. Commons and Guava are extremely popular and robust libraries and really should be included in any comparison against "real world"…

Still, Awk and Perl need no library, the semantics was the part of the language since the beginning, and is always available to every programmer, also for the bigger programs. Awk and Sed were obvious inspirations for Perl.
Post reply on HN