Talk:Standard streams

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Stdin to display status?[edit]

The GUIs section states that the dwm tiling window manager "uses its stdin to display status information". Is this correct? Surely stdout or stderr is intended. Nate (talk) 16:10, 20 March 2008 (UTC)[reply]

stdpasswd[edit]

Has anybody heard of stdpasswd used as a standardized stream anywhere? kostmo (talk) 04:21, 28 December 2008 (UTC)[reply]

C# Example[edit]

Monkeycoders on teh my wikipedia. Fixed for great coding style —Preceding unsigned comment added by 93.92.205.25 (talk) 08:06, 10 April 2009 (UTC)[reply]

FILENO[edit]

What does FILENO stand for? Thanks, --Abdull (talk) 11:22, 25 May 2010 (UTC)[reply]

I'm pretty sure it means file number. It's a very short name because of the limitations of 1970s era C compilers which typically ignored anything passed about 7 or 8 characters in an identifier. —EncMstr (talk) 17:11, 25 May 2010 (UTC)[reply]

Affected by proposed renaming[edit]

Presently standard error (presently disambiguation) and standard error stream are pointed to or redirect to this article. There is a formal proposed renaming/move at Talk:Standard error (statistics)#Requested move that would affect these routes to this article. Unfortunately, this discussion is only open for 7 days, so be quick if you want your opinion to count. Melcombe (talk) 19:30, 15 February 2012 (UTC)[reply]

Encoding inconsistency[edit]

I read Popular Windows programs that open a separate console window in addition to their GUI windows are the emulators pSX and DOSBox.

Nonethess, from my undesrstanding, Windows application run with text encoded in UTF-16, UTF-8, or windows-1252; when DOS box is configured for CP850. This mean that they cannot display the same set of character, and so their interoperability is limited, and cannot be used neither easily, nor by default which is opposite to the unix philosophy described in background section. — Preceding unsigned comment added by 86.75.160.141 (talk) 12:18, 11 November 2012 (UTC)[reply]

PHP[edit]

idk if it should go in the article, but in PHP, its php://stdin , php://stdout , php://stderr [1] since 2002 / PHP 4.3.0 [2][3] Divinity76 (talk) 15:41, 7 September 2013 (UTC)[reply]

  1. ^ http://www.php.net/manual/en/features.commandline.io-streams.php
  2. ^ http://www.php.net/manual/en/features.commandline.introduction.php
  3. ^ http://www.php.net/ChangeLog-4.php#4.3.0

Origin of stderr[edit]

While a bit unusual, I don't see why the material about the origin of stderr was removed. Yes, it's a self-published primary source, but the author can certainly be considered an expert, and I don't see anything in WP:V that prohibits this unless you think it's somehow controversial, which it's not as far as I know. Your comment about v6 makes no sense to me; Johnson doesn't say, but this would have been about 1973, and v6 wasn't released until 1975. Do you doubt this actually happened, or are you just unhappy with the source? Kendall-K1 (talk) 22:14, 19 December 2013 (UTC)[reply]

I am unhappy about several aspects:
  1. the source: I am not familiar with sjc @ yaccman. Is that a reliable source? Certainly the newsgroup is not fact checked.
  2. the assertion: While the story seems like it could be plausible, it doesn't need to be. Unix borrowed much from Multics which had stderr. Why would they not have added that with stdout?
  3. the lack of dates: If the event occurred in 1973, then that could fit. But nothing here gives dates.
While I would like to see any tidbit on the origin of these, the prime policy of verifiability being observed would help this lore be defended and greatly improve the article. —EncMstr (talk) 04:42, 20 December 2013 (UTC)[reply]
Bell Labs installed their CAT in 1973, and this would have been soon after that. S. C. Johnson worked there at the time. He was co-author with Kernighan of "THE PROGRAMMING LANGUAGE B" and several other CSTRs [1]. Unix did borrow a lot from Multics, but what really distinguished Unix was the vast amount of Multics stuff they deliberately left out. While the mailing list (not newsgroup) is not fact checked, I have no doubt this was actually written by scj. You could argue that his memory could be faulty. But this entire article is almost completely unsourced, so picking on one tidbit that actually is sourced seems odd to me. Kendall-K1 (talk) 11:48, 20 December 2013 (UTC)[reply]
Looking more deeply, seems like a valid cite to material of The Unix Heritage Society to me. If I could get a provenance like that - a written conversation between Douglas McIlroy and Larry McVoy and other prime movers - on other stories of computer history, I'd be grateful. Added back with clearer citation. ★NealMcB★ (talk) 20:03, 2 July 2015 (UTC)[reply]

Inconsistency[edit]

"stdin", "stdout" and "stderr" are "channels", "file handles" or "ports". They are not "streams". Calling them "streams" is inconsistent with the definition of Stream (computing): "a sequence of data elements made available over time"

When you "write data to stdout", the "stream" is *your data*, not "stdout". Std-out is just a standardized file handle number. The best analogy is a "channel". "stdout" is *where* you write the *stream* (your data).

Also here Redirection (computing) it reads: *"Redirecting to and from the standard file handles"*. What is "standard" in std-in and std-out is that input stream is read from file handle 0 and output stream is sent to file handle 1. "stdin" is a file handle, and the "input stream" is the data you receive by reading from stdin.

"stream" is data, while a "channel" is a medium. "stdin" and "stdout", from a programming point of view, are channels, mediums.

In the sentence "write data to stdout". *data* is the *stream* and "stdout" is the *channel*.

You cannot "write data to a stream", the data *is* the stream.

I believe this article should be called "Standard channels" or "Standard file handles", and also the text should be revised to avoid conflating "stream" with "channel".

Moreover, this article starts:

> "In computer programming, standard streams are preconnected input and output streams (communication channels)"

implying that a "stream" is a "communication channel" -which is not- by definition from this same encyclopedia: Stream (computing)

By replacing "stream" with "channel" in the text of the article, the inconsistencies are resolved.e.g.:

> "In computer programming, standard channels are preconnected input and output channels" — Preceding unsigned comment added by Luciotato (talk) 19:09, 23 January 2015 (UTC)[reply]

I suspect you are confused by C++ conventions which has a stream object type—which contains sequenced data—since the late 1980s; C++ streams are based on i/o streams from the 1970s which truly are a raw i/o mechanism and might contain any kind of data—keyboard input, line printer control instructions, or even C++ data object representations.
However, your interpretation is likely to be widespread among recent computer science students so some sort of clarification is justified. —EncMstr (talk) 19:31, 23 January 2015 (UTC)[reply]
I'm pointing out inconsistencies in the definition of terms. If the article title is "Standard streams" then why the first statement says "This article is about standard I/O file descriptors"?. Is a "stream" a "file descriptor"? or a stream is a "sequence of data"?
also from the article:
> ...are preconnected input and output streams (communication channels)
it is implying that a "Stream" is a "communication channel"?
Given the definition of Streams this article is misusing the term. Without considering any programming language, the usage of the word "stream" in this article is inconsistent with the definition of stream. It is a problem of internal consistency of the encyclopedia. Luciotato (talk) 19:59, 23 January 2015 (UTC)[reply]

There has always been this inconsistently with stream I/O. It is common to refer to stdin, stdout, and stderr as stream input and output channels. as the stdin input stream terminology I beleave predates the current stream I/O defination.

UNIX bullshit[edit]

Mainframe operating systems like RCA's TSOS had the abstracted devices the article claims for UNIX quite some time before UNIX! STDIN was read via RDATA macro/SVC, writing to STDOUT was done via WROUT macro/SVC. Assignment of the streams to file was done via the /SYSFILE JCL command. — Preceding unsigned comment added by 84.153.132.112 (talk) 19:32, 25 December 2017 (UTC)[reply]

FORTRAN77 example[edit]

Hi,
while the numbers in the FORTRAN77 example are indeed those often used for the standard streams (at least stdin and stdout, not sure about stderr), the FORTRAN77 language as standardised does only distinguish between standard input and standard output. Also it defines a portable way to excess those. The portable, standard-conforming variant of the example reads: 

C     FORTRAN 77 example
      PROGRAM MAIN
        INTEGER NUMBER
        READ(*,*) NUMBER
        WRITE(*,'(A,I3)') ' NUMBER IS: ',NUMBER
      END

More concisely one could code the example as 

C     FORTRAN 77 example
      PROGRAM MAIN
        INTEGER NUMBER
        READ *, NUMBER
        PRINT '(A,I3)', ' NUMBER IS: ',NUMBER
      END

The "!" as comment character was only introduced in Fortran90, btw.
Cheers
InfoBroker2020 (talk) 12:25, 14 May 2018 (UTC)[reply]

language’s English (en)
Username’s:
@KuGau0xxx 2603:8000:6202:D0C3:642D:2DD6:97E1:6E60 (talk) 05:13, 30 January 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Standard_streams&oldid=1211729321"