Computing desk
< November 6	<< Oct \| November \| Dec >>	November 8 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

November 7

Up-to-date news of Red Link Communications

Thank you for reading my question.I am a beginner of Wikipedia.I have a problem at editing on the article,Red Link Communications,that is already existed.I can't edit this article because I think the volunteer who worked for this article told me that I was writing and modifying for promotional purpose but I am not.I am from Asia.I want to know about the new information of Red Link Communications.Please answer my question and tell me what to do.
Thank you. — Preceding unsigned comment added by Lwt777 (talk • contribs) 08:08, 7 November 2013 (UTC)[reply]

Red Link Communications is the article in question. Looking at your edits I see the use of phrases like: "a leading and highly innovative ICT flagship", "The vision of RedLink is to become a world class Telecom Services Provider", and "kindly share that Chronologies of RedLink Communications Group to be public awareness in choosing the reliable and capable compan[y]". Why would you add such phrases if it is not for promotional purposes?

Please read "The five pillars of Wikipedia" - there is a link to the relevant page in the welcome message I have left on your talk page. You should also read Wikipedia's policy on promotion, and (because I suspect you might work for Red Link) you should also read Wikipedia's guideline on editing when you have a conflict of interest. Astronaut (talk) 12:40, 7 November 2013 (UTC)[reply]

I also removed you signature which appears to be at least partly impersonating another user. Astronaut (talk) 12:48, 7 November 2013 (UTC)[reply]

Thank you for reply.I need help on Wikipedia and you give a great help.I apologize for writing like this because I opened under the link and some of the link can't opened.Sorry for misunderstanding,I am not working for Red Link.Thank you and sorry.Lwt777 (talk) 10:36, 8 November 2013 (UTC)[reply]

I modified your signature which appears to be at least partly impersonating another user. Astronaut (talk) 12:39, 8 November 2013 (UTC)[reply]

stdout and stderr are there files too?

Everything is supposed to be a file. But how could I, say, output the head of one of those? OsmanRF34 (talk) 19:29, 7 November 2013 (UTC)[reply]

This is probably a good starting point for you. You can redirect the stdout or stderr to a file, or to the stdin of another process: Redirection (computing). Katie R (talk) 20:54, 7 November 2013 (UTC)[reply]

No, as far as I can understand, stdout and stderr are not necessarily files. You might have heard "everything is a file" in connection with the Unix philosophy, but stdout and stderr are most commonly associated with C, which really is independent of Unix, although it shares close connotations and connections with it. Properly speaking, stdout and stderr are output streams. Where these streams are going to is supposed to be independent of the program. They could go to files, but they could just as well go to a console display, or even to an Internet connection. JIP | Talk 20:57, 7 November 2013 (UTC)[reply]

Standard input and output streams can be treated like FILE pointers. However, some file operations will fail: for example, if you try to use fseek(stdin, 0, 0), the function will have no effect and will return error code EBADF because the stream is not seekable. When a unix programmer says "everything is a FILE," that is not the same as saying everything is a file. A unix programmer can only safely say everything is a FILE after they #include a standard library header - like stdio - that defines what a FILE is and how it is guaranteed to behave.

The principle at play here is that "FILE" is an abstraction of data that can be indexed serially. Any type of data can be indexed serially. If you have standard utility functions to deal with abstract serial data, without loss of generality, your utility functions must be able to report when some operations fail. If the file represents something that is not a series of data written to nonvolatile storage, and you try to treat it like that, then your utility functions will fail. If you write code that checks error-codes, and takes a reasonable action following an unexpected abstract error (whose root cause is unknown), then your program will work anyway. Nimur (talk) 23:54, 7 November 2013 (UTC)[reply]

As JIP points out, I think you're somewhat conflating files in the sense of C programming with files in the sense of the *nix kernel. Which, I grant you, the question does somewhat lend itself to, partially but not completely. --Trovatore (talk) 23:55, 7 November 2013 (UTC)[reply]

Right, they're not physical files on the disc, but from within C you can treat them like files. Looking at K&R's C book, 2nd edition, file access is covered in section 7.5 (pg 160). As far as C is concerned, they are files just like anything else, and the book words it "When a C program is started, the operating system environment is responsible for opening three files and providing file pointers for them. These files are the standard input, the standard output, and the standard error; the corresponding file pointers are called stdin, stdout, and stderr, and are declared in <stdio.h>. Normally stdin is connected to the keyboard and stdout and stderr are connected to the screen, but stdin and stdout may be redirected to files or pipes as described in Section 7.1." If you don't have that book yet, and plan on programming much C, then buy it. It is the standard reference for all sorts of C and C/Unix questions, and is very well written. I don't know a C programmer that doesn't have a copy on their shelf. Katie R (talk) 16:12, 8 November 2013 (UTC)[reply]

fseek(3) returns -1 on error, and the errno value I get is ESPIPE, not EBADF. (I don't remember what the C standard says here.) --Tardis (talk) 18:57, 8 November 2013 (UTC)[reply]

Thank you, your clarification is actually worded more correctly than what I wrote above. I believe the value in "errno" depends on which C standard library is in use (e.g., a version of BSD libc, or a version of the GNU libc, or some other library from some other source). For example, here's fseek.c used on Mac OS X: it can set errno to several possible values depending on the type of failure. Nimur (talk) 22:48, 8 November 2013 (UTC)[reply]