Difference between Cygwin and DOS handling of string input

[Michael Foukarakis]

There's a word for that. 'Denial'.

I guess we have different criteria for advanced or modern.  To me if I
BUY and install a distro [of whatever] then have to buy/find/scrounge
around for tools to actually make it useful, while many other distros
make that available by default... it's not an advanced OS.

I mean let's work down the list of things you don't get from a blank
Vista/Win7 install

- compiler, build tools like make, cvs/rcs, debuggers, etc...
- real shell [that is compatible with the 1000s upon 1000s of scripts
out there]
- remote shell access [rdesktop is cool but let's be real, TTY is
often better]
- Office Suite
- Image Editing Tools
- Audio Mixing Tools
- Tux Racer
- Ton of userland tools that make work possible (perl, sed, awk, grep,
find, xargs, gzip, ...)
- oh, and the source to all of that

Powershell. And cmd *is* a shell.

cmd.exe is a shell in that it's a TTY that lets you run commands, but
compared to the versatility of say bash ... get real.

And Powershell is not remotely compatible with sh/csh/tcsh/bash.  It
uses it's own scripting language because it's "special."

Please point me to the Linux/UNIX analogous of OllyDbg. Then you can
talk shit again.

Well show me in Win7 where you get tools like sed, perl, awk,
grep, ...

And before you comment on the usefulness, a very common one I get is
say you have a directory of 100s of files with the names like

Family_Summer_2007_*.jpg

And you want to change it to 2008.  How do you do that in Powershell
or cmd.exe?

I'm just going to redirect you to Command Line Kung Fu, an excellent
source of associated tricks. You have lots to learn, I suggest you
start fast.

After that, I also suggest you study the separation between an
operating system and user application.

Have fun.

 

[Nick]

On output to a text file, yes, but binary mode is best for handling a
protocol stream.


Not on a binary stream. The best way to ensure you get what you write
(or that you read what is really there) is to use binary mode for such
streams.

So how to I, portably, convert stdout to "binary mode"?

 

[Ben Bacarisse]

So how to I, portably, convert stdout to "binary mode"?

You can't. You can try, of course, with freopen but that can fail to
have the desired effect.

I hope you did not think I was saying that it's all easy and there is
no problem. I was just saying that a binary stream is the only
portable way go, despite the ensuing restrictions such as not being
able to use stdout for this purpose.

 

[Alan Curry]

So how to I, portably, convert stdout to "binary mode"?

How did you, "portably", get a socket on stdout?

 

[Richard Tobin]

How did you, "portably", get a socket on stdout?

I don't see the relevance of this question. The assumption is that
the program is run with stdout connected to a socket. How this is
done is irrelevant to the author of the C program. You might as
well ask "how do you portably run a program".

And of course the question of how to set stdout to binary mode is
applicable in other circumstances where the output is a file.

Incidentally, it's possible on many systems to open a socket using
only standard C functions.

-- Richard

 

[Flash Gordon]

What are you talking about? That is one the most ridiculous things even
you have posted.

I was pointing out how ridiculous your claim was. People not only pick
tools based on the OS they will use, but finances and all sorts of other
issues. So if having a bearing on the tools you chose is enough to make
something topical, finances are topical, as are politics, availability
of internet access, how close the local PCWorld is... the list is endless.

 

[Alan Curry]

I don't see the relevance of this question. The assumption is that
the program is run with stdout connected to a socket. How this is
done is irrelevant to the author of the C program. You might as
well ask "how do you portably run a program".

Seriously, why worry about how to do network protocols via stdin/stdout if
you don't have an actual use case? It happens with inetd for example, but I
don't think inetd is popular on Windows. It's not even popular on unix
anymore, with the most often-used daemons being standalone httpd and sshd.

And of course the question of how to set stdout to binary mode is
applicable in other circumstances where the output is a file.

Incidentally, it's possible on many systems to open a socket using
only standard C functions.

When you fopen() /dev/tcp you can say "r+b", which just leaves
stdin, stdout, and stderr as the only trouble spots.

If you want to be extreme about it, there's no way you can "portably" do
any Internet protocols in C, since they're all defined in terms of octets and
your system might have 11-bit chars and then there's no sequence of stdio
output calls that can possibly have the right number of bits to form the
correct sequence of 8-bit bytes. C is just not capable of being used for
network-related code apparently.

Meanwhile back in reality, things aren't as bad as the C Standard
hand-wringing might suggest. If this comes up at all, you start with code
assuming sane file semantics (i.e. "text mode" and "binary mode" are useless
jibber-jabber so just ignore them) and add #ifdef'ed "detextify(stdout)" code
for any outlying systems you care about.

 

[Seebs]

I was pointing out how ridiculous your claim was.

You write as though you think he can comprehend written English...

People not only pick
tools based on the OS they will use, but finances and all sorts of other
issues. So if having a bearing on the tools you chose is enough to make
something topical, finances are topical, as are politics, availability
of internet access, how close the local PCWorld is... the list is endless.

.... Or common forms of argument, in this case, reductio ad absurdum. So
I guess you're also assuming he can comprehend at least one thing written
in Latin.

-s

 

[Nick]

Seriously, why worry about how to do network protocols via stdin/stdout if
you don't have an actual use case? It happens with inetd for example, but I
don't think inetd is popular on Windows. It's not even popular on unix
anymore, with the most often-used daemons being standalone httpd and sshd.

I've got a use case. A C interpreter started by httpd (of some
variety). Even there, the specs say that after the Content-type I should
be sending "two carriage return/new line pairs" (eg
http://httpd.apache.org/docs/2.0/howto/cgi.html). In practice I've
never had a problem, and I suspect the web servers I've used are pretty
tolerant in what they want there. But, nevertheless, I'm intrigued as
to how I guarantee to send precisely that down stdout. After all, it's
possible to do significant amounts of server-side programming entirely
in standard C.

[The bit above where the snipping starts, was the statement that to do
it I needed to open the file in binary mode, hence my request. In
practice, I don't want to change the mode on stdout; I want to send a
particular byte sequence down stdout].

 

[Squeamizh]

I was pointing out how ridiculous your claim was. People not only pick
tools based on the OS they will use, but finances and all sorts of other
issues. So if having a bearing on the tools you chose is enough to make
something topical, finances are topical, as are politics, availability
of internet access, how close the local PCWorld is... the list is endless..

The state of one's finances is not topical, but the price of different
C tools is.