473,321 Members | 1,622 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,321 software developers and data experts.

safe scanf( ) or gets

Hi ! I was wondering how to quickly and safely use a safe scanf( ) or gets
function... I mean.. if I do :

char a[256];
scanf("%s", a);
and the user input a 257 char string..
that creates a problem.. same for gets..

even if you create a char array that's 99999999999999 char long.. if the
user input something longer it will still be a bug.. and I don't want
this..

<OT>
C++ have std::string that dynamicaly realloc themself if they are running
too big, but what about us ?
</OT>

I though about using character input function, from stdin, and then create a
string with this single character, then appending this character to the then
end of a string, and if the string gets too small, realloc( ) a bigger
one.. however this is quite annoying to do this each time I want to read
input.. yes I could create a function with this.. and that's what I gonna
do.. however I was wondering what you C experts were doing to avoid a
segfault or a bug in a such situation

thanks !
Nov 14 '05 #1
57 11665
nrk
Eric Boutin wrote:
Hi ! I was wondering how to quickly and safely use a safe scanf( ) or
gets
function... I mean.. if I do :

I don't know of any safe way to use gets. Use fgets instead where you can
specify the maximum number of characters to read into your buffer. With
scanf, the same can be achieved by specifying a maximum field width in the
conversion specifier (see below).
char a[256];
scanf("%s", a);
and the user input a 257 char string..
that creates a problem.. same for gets..

even if you create a char array that's 99999999999999 char long.. if the
user input something longer it will still be a bug.. and I don't want
this..

You can avoid this problem by specifying the maximum field width in the
conversion specifier:
scanf("%254s", a);
which will read a maximum of 254 characters into "a". Read the
documentation of scanf for more details.
<OT>
C++ have std::string that dynamicaly realloc themself if they are running
too big, but what about us ?
</OT>

You'll have to roll your own unfortunately... but... (see below)
I though about using character input function, from stdin, and then create
a string with this single character, then appending this character to the
then
end of a string, and if the string gets too small, realloc( ) a bigger
one.. however this is quite annoying to do this each time I want to read
input.. yes I could create a function with this.. and that's what I
gonna
do.. however I was wondering what you C experts were doing to avoid a
segfault or a bug in a such situation

Several regulars in this group (CBFalconer, Richard Heathfield, Morris
Dovey) have developed functions that do something along the lines of what
you want. Even if you want to roll your own, search the archives for a
thread with subject "Reading a line from a file" to get the URLs for the
same, to get a feel for how to go about it.

-nrk.

ps: This question seems to crop up so often around here that perhaps it
should be added to the FAQ?
thanks !


Nov 14 '05 #2

"Eric Boutin" <er**@nic.nac.wdyn.de> wrote in message

Hi ! I was wondering how to quickly and safely use a safe scanf( ) or > gets function... I mean.. if I do :

The real answer is that stdin is seldom used in real programs. If the
program takes a few parameters from the user these are passed on the command
line, if it needs a large number of inputs these are given in an ASCII file,
and if it really needs interactivity then it uses a GUI.

There are plenty of functions knocking around that read an arbitrary-length
string from stdin. You only have to write these once.

The advice to replace gets() with a call to fgets() and throw away the
trailing '\n' is bad, since you replace undefined behaviour with wrong
behaviour on overflow. To use fgets() properly you have to take action on
overflow, which makes the program complex.


Nov 14 '05 #3
"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:
The real answer is that stdin is seldom used in real programs.
I strongly disagree. In fact, to get any /real/ work done with a computer,
programs which read from standard input and write to standard output (AKA
filter programs) are absolutely mandatory, IMO.

Without filter programs, computers would be useless to me. (I would also
be unemployed, because my work would be impossible.)
if it needs a large number of inputs these are given in an ASCII file,
I don't understand. A text file can contain arbitrarily long lines, just
like standard input. How does reading from a file instead of standard
input change the situation?

(In fact, on many operating systems, standard input can be redirected
from a file, and a file name is provided for the terminal, so IMHO it
doesn't make much sense to distinguish between standard input and named
files.)
and if it really needs interactivity then it uses a GUI.


Again, if this is supposed to be general advice (it sounds as if it is,
sorry if I misunderstood you), I strongly disagree. Many people (including
myself) prefer non-GUI programs to GUI programs.

Martin
Nov 14 '05 #4

"Martin Dickopp" <ex****************@zero-based.org> wrote in
"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:
The real answer is that stdin is seldom used in real programs.
I strongly disagree. In fact, to get any /real/ work done with a
computer, programs which read from standard input and write to
standard output (AKA filter programs) are absolutely mandatory,
IMO.

Sound like someone knows about a world which I know nothing about.
and if it really needs interactivity then it uses a GUI.


Again, if this is supposed to be general advice (it sounds as if it is,
sorry if I misunderstood you), I strongly disagree. Many people
(including myself) prefer non-GUI programs to GUI programs.

Then we realise that we are more probably dealing with an eccentric. GUIs
have swept the board for interactive programs.
I don't know about filter programs - maybe in mainframe environments with
non-user generated stdin. As a games programmer I would never use nor write
a program written in such a fashion.
Nov 14 '05 #5
Malcolm wrote:
"Eric Boutin" <er**@nic.nac.wdyn.de> wrote in message
Hi ! I was wondering how to quickly and safely use a safe scanf( ) or >
gets function... I mean.. if I do :

The real answer is that stdin is seldom used in real programs. If the
program takes a few parameters from the user these are passed on the command
line, if it needs a large number of inputs these are given in an ASCII file,
and if it really needs interactivity then it uses a GUI.


This is grossly untrue. *Many* real programs are filters, taking stdin as
the default source.

There are plenty of functions knocking around that read an arbitrary-length
string from stdin. You only have to write these once.

The advice to replace gets() with a call to fgets() and throw away the
trailing '\n' is bad, since you replace undefined behaviour with wrong
behaviour on overflow. To use fgets() properly you have to take action on
overflow, which makes the program complex.


This is ridiculous. Only someone who doesn't know how to discard the '\n'
properly could have written such drivel. Of course it is not "bad" to call
fgets() and discard the trailing '\n'. What is necessary is to decide what
to do when there is no trailing '\n', and the level of complexity involved
need not be large at all.

--
Martin Ambuhl

Nov 14 '05 #6
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"Martin Dickopp" <ex****************@zero-based.org> wrote:
"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:
The real answer is that stdin is seldom used in real programs.
I strongly disagree. In fact, to get any /real/ work done with a
computer, programs which read from standard input and write to
standard output (AKA filter programs) are absolutely mandatory,
IMO.

Sound like someone knows about a world which I know nothing about.


You don't know about operating systems providing command line
interfaces? Can't believe that.
and if it really needs interactivity then it uses a GUI.


Again, if this is supposed to be general advice (it sounds as if it is,
sorry if I misunderstood you), I strongly disagree. Many people
(including myself) prefer non-GUI programs to GUI programs.

Then we realise that we are more probably dealing with an eccentric.


Nobody preferring a console interface over a GUI is an eccentric,
but someone who knows about the power of command lines.
GUIs
have swept the board for interactive programs.
stdin and interactive input are not equivalent. In a typical
environment input and output of a program are often redirected
to/from other sources. Remember: stdin/stdout/stderr are streams
which may be connected to a console, or a physical file. From C's
POV there's no difference, hence the rule: never use gets (for
suitable values of 'never').
I don't know about filter programs - maybe in mainframe environments with
non-user generated stdin.
A lot of standard command line utilities on a vast number of OSs are
filter programs. For example, you virtually can't do anything useful
on a typical *nix system without using stream filters, e.g. grep,
head, tail, sed, awk, gzip, more, cut, sort, ...
As a games programmer I would never use nor write
a program written in such a fashion.


Not all the world is a Wintel box. ;-)

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.angelfire.com/ms3/bchambl...me_to_clc.html
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...acllc-c++.html
Nov 14 '05 #7

"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message

Then we realise that we are more probably dealing with an eccentric.
Nobody preferring a console interface over a GUI is an eccentric,
but someone who knows about the power of command lines.

No its eccentric. Users generally won't accept command line programs unless
forced to use them. A GUI is generally far easier to use - I'm typing this
into a GUI newsreader.
A lot of standard command line utilities on a vast number of OSs are
filter programs. For example, you virtually can't do anything useful
on a typical *nix system without using stream filters, e.g. grep,
head, tail, sed, awk, gzip, more, cut, sort, ...
Well grep you would usually invoke with the name of the file to search.
"more" does use redirection, and it is a quirky thing to use - basically a
patch on the other utilities not being GUI. I have never had any reason to
use the other utilities mentioned.
Not all the world is a Wintel box. ;-)

Just the vast majority of general-purpose computers in use today. Even jobs
that used to require a mainframe can now often be done on PCs. Things like
supermarket checkouts and airport information screens are often PCs
underneath.
The vast majority of medium-sized systems that aren't PCs are probably games
consoles. They don't use command lines either. Nor do mobile phones.

Nov 14 '05 #8

"Martin Ambuhl" <ma*****@earthlink.net> wrote in message

This is ridiculous. Only someone who doesn't know how to discard
the '\n' properly could have written such drivel.
Well the FAQ showed to "replace gets() with a call to fgets()", and
discarded the trailing '\n', which means that undefined behaviour on
overflow is very likely to be replaced by incorrect behaviour on overflow.

If an experienced programmer like Steve Summitt can't get it right, then I
think we can say that fgets() is difficult to use.
Of course it is not "bad" to call fgets() and discard the trailing '\n'.
What is necessary is to decide what to do when there is no trailing '\n',
So how do you determine if there is no trailing '\n', if it's been
discarded?
and the level of complexity involved need not be large at all.

It depends what you mean. If you are comparing to some sort of analysis of
equations used in particle physics then, no, its not complicated. If you
mean that it adds substantial extra hassle to what should be a simple
process of getting a line from the user, then, yes, using fgets() properly
is complicated. You need to check the '\n', then discard the remainder of
the line, report an error message to the user (probably), and then loop to
get another line.
Nov 14 '05 #9

On Sun, 14 Dec 2003, Malcolm wrote:

"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message

Nobody preferring a console interface over a GUI is an eccentric,
Careful about those generalizations, Irrwahn -- I bet I could
provide a few counter-examples if provoked. :)
but someone who knows about the power of command lines.


No its eccentric. Users generally won't accept command line programs unless
forced to use them. A GUI is generally far easier to use - I'm typing this
into a GUI newsreader.


Yes, and that's precisely one of the examples I was going to
bring up prevthread, as one of your apps requiring "more complicated
input" than your average non-GUI app can deliver. Also text editors
and programs computation- or I/O-heavy enough to really *require* a
progress indicator (e.g., my system's default invocation of 'wget').
Line-based text editors do exist, but IMHO only eccentrics really
*do* use those. ;-)
However, I frequently use a command-line compiler (gcc), which
is IMHO orders of magnitude more powerful and user-friendly than
the typical Visual offering. And of course if you've ever used
an MS-DOS Command Prompt on your Wintel box, you've seen how programs
like 'copy' and 'dir' can be useful from time to time. :)

A lot of standard command line utilities on a vast number of OSs are
filter programs. For example, you virtually can't do anything useful
on a typical *nix system without using stream filters, e.g. grep,
head, tail, sed, awk, gzip, more, cut, sort, ...

Well grep you would usually invoke with the name of the file to search.


Yes, but you may not have known that you can *also* invoke 'grep'
like this:

c:\> grep 'hello' < myfile.txt
or
c:\> dir /s | grep "myprog.exe" | sort

which last is a complex operation which to my knowledge cannot be
performed by any of the out-of-the-box GUI tools on Windows XP
(although third-party tools exist, of course). See, command-line
tools can be very useful for the everyday tasks of people who know
and use computers every day -- even if gamers don't need them.

Not all the world is a Wintel box. ;-)


Just the vast majority of general-purpose computers in use today. Even jobs
that used to require a mainframe can now often be done on PCs. Things like
supermarket checkouts and airport information screens are often PCs
underneath.
The vast majority of medium-sized systems that aren't PCs are probably games
consoles. They don't use command lines either. Nor do mobile phones.


BZZT. How do you think those phones are programmed? I'm willing
to bet, even though I don't know, that the guys who work for Nokia
or whatever have on their desks little gray boxes with cords that
plug into ports on the phones and interface with the phone's
file system at a rudimentary command line level. Because line-
driven shells are easy to write, and GUIs are hard (generally
speaking).
And a note in passing to look up "Linux" sometime -- it looks
like it might be becoming more popular in both the commercial and
home markets. :)

-Arthur
Nov 14 '05 #10

On Sun, 14 Dec 2003, Martin Ambuhl wrote:

Malcolm wrote:
"Eric Boutin" <er**@nic.nac.wdyn.de> wrote in message
Hi ! I was wondering how to quickly and safely use a safe scanf( ) or >


gets function... I mean.. if I do :

The real answer is that stdin is seldom used in real programs. If the
program takes a few parameters from the user these are passed on the command
line, if it needs a large number of inputs these are given in an ASCII file,
and if it really needs interactivity then it uses a GUI.


This is grossly untrue. *Many* real programs are filters, taking stdin as
the default source.


However, do many of those programs use gets() or scanf()? My
experience is that the simpler ones often use state machines based on
getc(), and the more complicated ones often allow the user to
specify files either directly or implicitly, which means using a
FILE * variable, which rules out scanf() and gets() right off the
bat (since they *only* read from stdin -- not that that doesn't
rule out fscanf(stdin,...), of course).
There are plenty of functions knocking around that read an arbitrary-length
string from stdin. You only have to write these once.

The advice to replace gets() with a call to fgets() and throw away the
trailing '\n' is bad, since you replace undefined behaviour with wrong
behaviour on overflow. To use fgets() properly you have to take action on
overflow, which makes the program complex.


This is ridiculous. Only someone who doesn't know how to discard the '\n'
properly could have written such drivel. Of course it is not "bad" to call
fgets() and discard the trailing '\n'. What is necessary is to decide what
to do when there is no trailing '\n', and the level of complexity involved
need not be large at all.


Right. Remember, often the goal is *not* to read a whole line of
input no matter what. A lot of the time, the goal is to process some
reasonable set of data that a benevolent user is inputting. So the
pseudocode goes like this:

Try to get some data.
Are the data reasonable?
Process them.
else
Reject them.

This is *easily* implemented in C as something like

p = fgets(buffer, sizeof buffer, fp);
if (p && buffer[strlen(buffer)-1]=='\n')
process(buffer);
else
do_error("Line too long, or EOF reached\n");

No problem! The fact that we raise an error on long lines,
instead of trying to read the line anyway, doesn't matter,
because a too-long line is in most cases an indication of
badly formed input. (A program source file, or an ASCII text
file, with 1000-character lines, is almost certainly malformed
or flat-out malicious. In applications where this is not
the case, of course, one must take appropriate measures.)

The gets()/fgets() issue is that replacing gets() with
fgets() replaces UNdefined behavior with DEFINED behavior,
and that's a *gigantic* step in the right direction. Dealing
with malicious input in a domain-specific way may be important,
but the fact that now an attacker *cannot* crash your program
is more important than the fact that he'll get a snide error
message when he tries.

-Arthur
Nov 14 '05 #11
Malcolm wrote:
"Martin Ambuhl" <ma*****@earthlink.net> wrote in message

Of course it is not "bad" to call fgets() and discard the trailing '\n'.
What is necessary is to decide what to do when there is no trailing '\n',


So how do you determine if there is no trailing '\n', if it's been
discarded?


This question demonstrates that you have no clue. Please learn something
about programming before posting your opinions, which have all bee
ill-considered so far.

--
Martin Ambuhl

Nov 14 '05 #12

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message

However, I frequently use a command-line compiler (gcc), which
is IMHO orders of magnitude more powerful and user-friendly than
the typical Visual offering.
It is easy to write a bad GUI. Visual C is fine most of the time, but
occasionally won't let you into the system. For instance, I once made the
mistake of allowing it to create a "shell" project for me. It created a
header called "stdafx.h", then when I added a pre-existing source file,
started complaining about precompiled headers not being found an all sorts
of nuisance. After about a hour messing about with it I finally gave up,
deleted, and started over by hand. For functions designed to save time, such
as pre-compiled headers and wizards, actually became time wasters. This is
quite common.
Using a non-GUI compiler, for a simple program it is of course easier to
type "cc foo.c" and everything will work. For a complex program you would
use make and a makefile (not stdin). make files aren't the easiest things to
write and maintain, though at least you are in control.
Yes, but you may not have known that you can *also* invoke 'grep'
like this:

c:\> grep 'hello' < myfile.txt
or
c:\> dir /s | grep "myprog.exe" | sort
And that's the sort of reason why users won't accept command lines.
Using Windows "find" we can look for files or folders named "myprog.exe",
and the GUI leads us through it. We can then double-click on the icons it
brings up to see what's in them. However you do lose some flexibility - you
can't pipe to your own version of "sort" which handles numerical values as
numbers (so x2 is before x11), for instance.
BZZT. How do you think those phones are programmed? I'm willing
to bet, even though I don't know, that the guys who work for Nokia
or whatever have on their desks little gray boxes with cords that
plug into ports on the phones and interface with the phone's
file system at a rudimentary command line level.
Never programmed a phone but it probably works on the same priciple as a
console.
You have a card which fits into the PC, and downloads the program into the
phone. A phone won't have a file system in the sense that you mean. Often
there'll be lots of turning the phone on and off to clear its memory.
Because line-driven shells are easy to write, and GUIs are hard
(generally speaking).
There's some truth in this. If you have a market of only a few hundred for
you compiler then it's hard to justify writing an expensive GUI for it.
However often it will be written so that it plugs into the VC++ GUI.
Similarly the program to download the executable into the phone might be
command line, though generally the command line programs are being replaced
by GUIs
And a note in passing to look up "Linux" sometime -- it looks
like it might be becoming more popular in both the commercial and
home markets. :)

It's only likely to succeed if it can protect the user from needing to use
the command shell. I can't use it since I need to run programs that only
work on Windows.
Nov 14 '05 #13
Arthur J. O'Dwyer wrote:
On Sun, 14 Dec 2003, Martin Ambuhl wrote:
Malcolm wrote:
"Eric Boutin" <er**@nic.nac.wdyn.de> wrote in message
Hi ! I was wondering how to quickly and safely use a safe scanf( ) or >

gets function... I mean.. if I do :

The real answer is that stdin is seldom used in real programs. If the
program takes a few parameters from the user these are passed on the command
line, if it needs a large number of inputs these are given in an ASCII file,
and if it really needs interactivity then it uses a GUI.


This is grossly untrue. *Many* real programs are filters, taking stdin as
the default source.

However, do many of those programs use gets() or scanf()?


Irrelevant. The grossly untrue statement is "stdin is seldom used in real
programs." There is nothing in that statement referring to gets() or
scanf(). His "real answer" was either a lie or a sign that he has no idea
what he is talking about.

The "real answer" is to learn to use stdin correctly; claiming that it is
seldom used is either a lie or stupid.


--
Martin Ambuhl

Nov 14 '05 #14

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message

The gets()/fgets() issue is that replacing gets() with
fgets() replaces UNdefined behavior with DEFINED behavior,
and that's a *gigantic* step in the right direction.

Defined wrong behaviour can be worse than undefined behaviour. The goal is
not just to prevent the computer from crashing, but to prevent any sort of
undesired behaviour. A crash is actually the least dangerous malfunction -
no diferrent to the computer blowing a fuse. What is really dangerous is
wrong but reasonable-looking results.
Nov 14 '05 #15

"Martin Ambuhl" <ma*****@earthlink.net> wrote in message

The "real answer" is to learn to use stdin correctly; claiming that it is
seldom used is either a lie or stupid.

stdin in is commonly used in beginner programs. It is old-fashioned and is
seldom used in most areas of computing. Interaction with computers is via a
GUI, and lengthy input is by files, and generally it does not make sense to
pipe these to standard input.
You may be working with a legacy system where modern practises haven't
arrived, but don't pretend that this is common.
Nov 14 '05 #16
On Sun, 14 Dec 2003 22:07:42 -0000, in comp.lang.c , "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:

"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message
>
> Then we realise that we are more probably dealing with an eccentric.
Nobody preferring a console interface over a GUI is an eccentric,
but someone who knows about the power of command lines.

No its eccentric. Users generally won't accept command line programs unless
forced to use them.


Donkeys gonads. Users accept any blasted program that they're paid to
operate. /Your/ users may be a collection of gollums hunched over
their gamepads, but mine live out in the real world, where they're
hired to, say trade bonds, and just fscking well get on with it using
a megaphone and some counting beads if we say so. Of course, generally
we let them have an HP desk calculator and a telephone if they start
making money. :-)
A GUI is generally far easier to use -
Pardon me, but b*llsh*t. I have an office full of users who require
fulltime assistance just to log their computers on in the morning. And
all of these guys have degrees.
GUIs are notoriously difficult to master. Few people get beyond the
basics, and still do most of their actual work by typing stuff in.
Not all the world is a Wintel box. ;-)

Just the vast majority of general-purpose computers in use today. Even jobs
that used to require a mainframe can now often be done on PCs. Things like
supermarket checkouts and airport information screens are often PCs
underneath.


True, but irrelevant.
The vast majority of medium-sized systems that aren't PCs are probably games
consoles.
Ha! You'd better come down off that ivory tower soon ....
They don't use command lines either. Nor do mobile phones.


Pray tell me, how /do/ you send an text without typing?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #17
On Sun, 14 Dec 2003 23:11:13 -0000, in comp.lang.c , "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:
And a note in passing to look up "Linux" sometime -- it looks
like it might be becoming more popular in both the commercial and
home markets. :)
It's only likely to succeed if it can protect the user from needing to use
the command shell.


You may want to pop over to the Mac groups sometime before making
absurd statements like this. Mac users are actually glad have a CLI at
last.
I can't use it since I need to run programs that only
work on Windows.


SoftWindows.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #18
"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:
lengthy input is by files, and generally it does not make sense to
pipe these to standard input.


On the contrary, the larger the amount of data to be processed, the more
sense it makes to pipe it to standard input. Imagine a pipe of several
filter programs; each one has its stdin connected to the stdout of the
previous program in the pipe and its stdout connected to the stdin of the
next one. If it were necessary to create a file at each intermediate step,
that would be a great waste of both performance and disk space.

Martin
Nov 14 '05 #19
Mark McIntyre <ma**********@spamcop.net> wrote:
On Sun, 14 Dec 2003 23:11:13 -0000, in comp.lang.c , "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:
And a note in passing to look up "Linux" sometime -- it looks
like it might be becoming more popular in both the commercial and
home markets. :)

It's only likely to succeed if it can protect the user from needing to use
the command shell.


You may want to pop over to the Mac groups sometime before making
absurd statements like this. Mac users are actually glad have a CLI at
last.


Not true.

I know several Mac users who hate it and everything about it and the
fact that sometimes they have to use it.

However, others, like me, are happy with the UNIX core and the extra
access to some great software it offers.

Malcolm, is, of course, correct. A CLI system will never be popular
among the general population as the vast majority of people will never
want to deal with the learning curve because they have no need for the
extra abilities it provides.


--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===
Nov 14 '05 #20
Malcolm wrote:

"Martin Ambuhl" <ma*****@earthlink.net> wrote in message

The "real answer" is to learn to use stdin correctly; claiming that it is
seldom used is either a lie or stupid.

stdin in is commonly used in beginner programs. It is old-fashioned and is
seldom used in most areas of computing. Interaction with computers is via a
GUI, and lengthy input is by files, and generally it does not make sense to
pipe these to standard input.
You may be working with a legacy system where modern practises haven't
arrived, but don't pretend that this is common.


I have been using Unix/DOS pipes for 20+ years. I've
never had a Unix pipe stack dump, once, except
when an element of the pipe was under development.

It was no more a struggle to accept responsibility for
constraining line length to a resonable value than any
other responsibility, since the contents of all files
being "piped" were under control of the people on the
projects involved.

GUI tools, on the other hand, stack dump on a regular basis.
At more that one installation *it became standard practice
to reboot one particular server periodically to "cure" a
well-documented and well-known memory leak* in the blasted
thing. This for a very expensive software package. This
state of the art prevailed for *over one year*, and still
prevails, so far as I know. This is also a very mission
critical package.

Since the leading offender in terms of viral infection by
memory ovwerwrite is by declaration a GUI-only solution
( Windows ), I find the irony of this statement most amusing.

And the *kewlest*, Most eXtreme form of GUIism, the actively
server-generated website, will *invariably* crash, for no
good reason, at random intervals. All HTTP clients leak
memory like a seive and crash merrily. The higher level
the tool (measure din Monster postings per package) used
to generate the website, the more frequent the crash.

Viva los CLI! GUIs are for people who can't operate text
editors! :) Add a CLI to a product lacking one, and you
will receive the most extreme gratitude of those who use
the thing :) See also "Cisco Corporation". At least they'll
be able to configure boxes while the GUI people are
consuming JOlt and pizza, mounrfully pulling all nighters
because the toolset is broken.

A good GUI is a joy to behold. There are , unfortunately,
almost no examples of a good GUI. The VC IDE is almost
the worst I have ever seen - without the help system, it'd
be unnavigable.

--
Les Cargill
Nov 14 '05 #21
Mark McIntyre <ma**********@spamcop.net> wrote:
A GUI is generally far easier to use -


Pardon me, but b*llsh*t. I have an office full of users who require
fulltime assistance just to log their computers on in the morning. And
all of these guys have degrees.
GUIs are notoriously difficult to master. Few people get beyond the
basics, and still do most of their actual work by typing stuff in.


I am sure that if you wanted to look into it, you would discover the
research studies which show that a well-designed GUI is easier.

Unfortunately, it is quite easy to implement a poor GUI. Designing a
good GUI is not easy and takes far more thought and effort then many
have been willing to put into some of them.
--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ===
"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
== Insults, like violence, are the last refuge of the incompetent... ===
Nov 14 '05 #22
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:
<...>
"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message

Nobody preferring a console interface over a GUI is an eccentric,


Careful about those generalizations, Irrwahn -- I bet I could
provide a few counter-examples if provoked. :)


Well, so could I. :) What I wanted to write is: Nobody is eccentric,
just because he prefers console interfaces...

<snip>

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.angelfire.com/ms3/bchambl...me_to_clc.html
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...acllc-c++.html
Nov 14 '05 #23
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message <snip>
Nobody preferring a console interface over a GUI is an eccentric,
but someone who knows about the power of command lines.

No its eccentric. Users generally won't accept command line programs unless
forced to use them. A GUI is generally far easier to use - I'm typing this
into a GUI newsreader.


So do I, as you can see from the headers. But when this message pops
up on your side, it has passed several systems, most of which are most
likely administered via command line interfaces. So the maintainers
of the internet infrastructure are eccentric because of this? BS.
A lot of standard command line utilities on a vast number of OSs are
filter programs. For example, you virtually can't do anything useful
on a typical *nix system without using stream filters, e.g. grep,
head, tail, sed, awk, gzip, more, cut, sort, ...

Well grep you would usually invoke with the name of the file to search.
"more" does use redirection, and it is a quirky thing to use - basically a
patch on the other utilities not being GUI. I have never had any reason to
use the other utilities mentioned.


Who is eccentric now? ;)
Not all the world is a Wintel box. ;-)

Just the vast majority of general-purpose computers in use today. Even jobs
that used to require a mainframe can now often be done on PCs. Things like
supermarket checkouts and airport information screens are often PCs
underneath.


What have mainframes to do with this?
The vast majority of medium-sized systems that aren't PCs are probably games
consoles.
Not where I live. There's more than mainframes, PCs and game
consoles, you know...

And if you are really into game development you most certainly
encountered some kind of debugging interface built into the game
engine, which is nothing else but... yes, a command line interface.
They don't use command lines either. Nor do mobile phones.


The last time I checked my cell phone didn't have a GUI.

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.angelfire.com/ms3/bchambl...me_to_clc.html
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...acllc-c++.html
Nov 14 '05 #24
In article <3F***************@worldnet.att.net>,
Les Cargill <lc******@worldnet.att.net> wrote:
server-generated website, will *invariably* crash, for no
good reason, at random intervals. All HTTP clients leak
memory like a seive and crash merrily.
Counterexample:
--------
dave@goofy:~ (1) $ telnet www.google.com 80
Trying 216.239.41.99...
Connected to www.google.com.
Escape character is '^]'.
get /search?q=small+http+client http/1.0

HTTP/1.0 200 OK
Cache-control: private
Content-Type: text/html
Set-Cookie: PREF=ID=33d2dac260e57c2e:TM=1071446738:LM=10714467 38:S=IBljKP6SXXt9Z0tq; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Server: GWS/2.1
Date: Mon, 15 Dec 2003 00:05:38 GMT
Connection: Close

[snip page text]
--------
telnet is also a nice, easy, stable POP/SMTP client (and, I'm sure,
would also be a nice, easy, stable NNTP client if I could be bothered
to learn the protocol). Not necessarily something I'd want to use all
the time, but I've never known it to leak memory or crash.

Viva los CLI! GUIs are for people who can't operate text
editors! :) Add a CLI to a product lacking one, and you
will receive the most extreme gratitude of those who use
the thing :) See also "Cisco Corporation". At least they'll
be able to configure boxes while the GUI people are
consuming JOlt and pizza, mounrfully pulling all nighters
because the toolset is broken.

A good GUI is a joy to behold. There are , unfortunately,
almost no examples of a good GUI.


Seconded.
There are a lot of ways to get GUIs right (and, sadly, infinitely more
to get them wrong), but all the ways I've ever seen to get them right
have two characteristics in common:
-There is a way to type in commands to do things that the GUI Just
Can't Do, because there isn't room for all the pointy-clicky stuff it
would require to do it;
-The average user never needs to be aware of the existence of such
an escape hatch, and even the most advanced user seldom needs to use
it, because the GUI is not only sufficient but also effective for all
but the most arcane tasks that may need to be done.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca

Please ensure that your teacher gets fired for incompetence.
--Dann Corbit in comp.lang.c
Nov 14 '05 #25
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message

The gets()/fgets() issue is that replacing gets() with
fgets() replaces UNdefined behavior with DEFINED behavior,
and that's a *gigantic* step in the right direction.
Defined wrong behaviour can be worse than undefined behaviour. The goal is
not just to prevent the computer from crashing, but to prevent any sort of
undesired behaviour. A crash is actually the least dangerous malfunction -
no diferrent to the computer blowing a fuse.


What is really dangerous is people making such claims. And yet it is
so dead easy to achieve well defined behaviour *and* get the desired
results...
What is really dangerous is
wrong but reasonable-looking results.


And that is exactely what you will get (according to Murphy's Law)
when you write code that invokes undefined behaviour, for example by
using gets. Nothing forces the program to crash on buffer overrun,
virtually anything can happen, from seemingly correct operation to
Nasal Demons taking over the world.

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.angelfire.com/ms3/bchambl...me_to_clc.html
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...acllc-c++.html
Nov 14 '05 #26
Dave Vandervies wrote:

In article <3F***************@worldnet.att.net>,
Les Cargill <lc******@worldnet.att.net> wrote:
server-generated website, will *invariably* crash, for no
good reason, at random intervals. All HTTP clients leak
memory like a seive and crash merrily.


Counterexample:
--------
dave@goofy:~ (1) $ telnet www.google.com 80
Trying 216.239.41.99...
Connected to www.google.com.
Escape character is '^]'.
get /search?q=small+http+client http/1.0

HTTP/1.0 200 OK
Cache-control: private
Content-Type: text/html
Set-Cookie: PREF=ID=33d2dac260e57c2e:TM=1071446738:LM=10714467 38:S=IBljKP6SXXt9Z0tq; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Server: GWS/2.1
Date: Mon, 15 Dec 2003 00:05:38 GMT
Connection: Close

[snip page text]
--------
telnet is also a nice, easy, stable POP/SMTP client (and, I'm sure,
would also be a nice, easy, stable NNTP client if I could be bothered
to learn the protocol). Not necessarily something I'd want to use all
the time, but I've never known it to leak memory or crash.


I wouldn't have originally considered
Telnet to be an HTTP client. I was really more thinking "web
browser". And some of the simpler web browsers may actually
not be leaky, but I dunno.
Viva los CLI! GUIs are for people who can't operate text
editors! :) Add a CLI to a product lacking one, and you
will receive the most extreme gratitude of those who use
the thing :) See also "Cisco Corporation". At least they'll
be able to configure boxes while the GUI people are
consuming JOlt and pizza, mounrfully pulling all nighters
because the toolset is broken.

A good GUI is a joy to behold. There are , unfortunately,
almost no examples of a good GUI.


Seconded.
There are a lot of ways to get GUIs right (and, sadly, infinitely more
to get them wrong), but all the ways I've ever seen to get them right
have two characteristics in common:
-There is a way to type in commands to do things that the GUI Just
Can't Do, because there isn't room for all the pointy-clicky stuff it
would require to do it;
-The average user never needs to be aware of the existence of such
an escape hatch, and even the most advanced user seldom needs to use
it, because the GUI is not only sufficient but also effective for all
but the most arcane tasks that may need to be done.

dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca

Please ensure that your teacher gets fired for incompetence.
--Dann Corbit in comp.lang.c

--
Les Cargill
Nov 14 '05 #27
On Sun, 14 Dec 2003 19:14:07 -0000 Malcolm <ma*****@55bank.freeserve.co.uk> wrote:

| Then we realise that we are more probably dealing with an eccentric. GUIs
| have swept the board for interactive programs.

It seems you are blind to reality. Sure there are plenty of GUI programs
and more coming along. But there are plenty of non-GUI programs around.
If every non-GUI program were to suddenly disappear, everything ... and I
do mean everything ... in the world would come to a screeching halt (much
of it because all the electric grids will be down).
| I don't know about filter programs - maybe in mainframe environments with
| non-user generated stdin. As a games programmer I would never use nor write
| a program written in such a fashion.

Your breadth of exposure to the field of computers is very narrow indeed.
Sure games are big, and there's money in games. But the real world is no
game. You better hope the game markets keeps going as I feel you could
not make it in any other field.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Nov 14 '05 #28
On Sun, 14 Dec 2003 22:07:42 -0000 Malcolm <ma*****@55bank.freeserve.co.uk> wrote:

| "Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message
|> >
|> > Then we realise that we are more probably dealing with an eccentric.
|>
|> Nobody preferring a console interface over a GUI is an eccentric,
|> but someone who knows about the power of command lines.
|>
| No its eccentric. Users generally won't accept command line programs unless
| forced to use them. A GUI is generally far easier to use - I'm typing this
| into a GUI newsreader.

You might call me eccentric, but GUIs really do slow me down. They are
most certainly NOT more powerful. CLI is the power. The catch is, CLI
requires extra effort to learn because it doesn't have much of a crutch
to lean on like some GUIs do. But it's obviously something you would
not be able to learn.
| Just the vast majority of general-purpose computers in use today. Even jobs
| that used to require a mainframe can now often be done on PCs. Things like
| supermarket checkouts and airport information screens are often PCs
| underneath.
| The vast majority of medium-sized systems that aren't PCs are probably games
| consoles. They don't use command lines either. Nor do mobile phones.

You are living in a virtual game world apart from reality.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Nov 14 '05 #29
Malcolm wrote:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message

However, I frequently use a command-line compiler (gcc), which
is IMHO orders of magnitude more powerful and user-friendly than
the typical Visual offering.
It is easy to write a bad GUI. Visual C is fine most of the time, but
occasionally won't let you into the system. For instance, I once made the
mistake of allowing it to create a "shell" project for me. It created a
header called "stdafx.h", then when I added a pre-existing source file,
started complaining about precompiled headers not being found an all sorts
of nuisance. After about a hour messing about with it I finally gave up,
deleted, and started over by hand.


Yes, these things should be turned off by default, IMHO.
For functions designed to save time,
such as pre-compiled headers and wizards, actually became time wasters.
This is quite common.
Right so far. Great! I am in complete agreement with you!
Using a non-GUI compiler, for a simple program it is of course easier to
type "cc foo.c" and everything will work.
Still in full agreement. Surely this can't last?
For a complex program you would
use make and a makefile (not stdin). make files aren't the easiest things
to write and maintain, though at least you are in control.
And of course you have full access to stdin within the programs invoked by
make, should you need it.
Yes, but you may not have known that you can *also* invoke 'grep'
like this:

c:\> grep 'hello' < myfile.txt
or
c:\> dir /s | grep "myprog.exe" | sort

And that's the sort of reason why users won't accept command lines.


Actually, it's a good reason why they might. But we aren't even beginning to
scratch the surface of the CLI's power. Here's a very slightly more
powerful example. In my dev directory, I have 72 subdirectories at present.

How do I know? ls -al | grep ^d | wc -l - that's how!

Okay, so where in that lot do I use my routines to connect to, or disconnect
from, an SMTP server? Ah...

find dev -name \*.c | xargs grep SMTP[CD]
Using Windows "find" we can look for files or folders named "myprog.exe",
and the GUI leads us through it.
Yes, and it's *slow*. What's more, it's harder to use than a CLI (IMHO,
having tried both).
We can then double-click on the icons it
brings up to see what's in them.
Doesn't sound very scriptable to me.
However you do lose some flexibility -
you can't pipe to your own version of "sort" which handles numerical
values as numbers (so x2 is before x11), for instance.
That's not the only flexibility you lose.

<snip>
And a note in passing to look up "Linux" sometime -- it looks
like it might be becoming more popular in both the commercial and
home markets. :)

It's only likely to succeed if it can protect the user from needing to use
the command shell.


On the contrary, it has already succeeded. Incidentally, just like Windows,
it gives the user the *choice* of a powerful[1] command shell, or a weak
but pretty GUI.

[1] The default Windows command shell is nowhere near as powerful as Linux's
various shells, IMHO, but hey, you can always use Cygwin.
I can't use it since I need to run programs that only
work on Windows.


Why not do the world a favour and port them to Linux? :-)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #30
Malcolm wrote:

"Martin Ambuhl" <ma*****@earthlink.net> wrote in message

This is ridiculous. Only someone who doesn't know how to discard
the '\n' properly could have written such drivel.

Well the FAQ showed to "replace gets() with a call to fgets()", and
discarded the trailing '\n', which means that undefined behaviour on
overflow is very likely to be replaced by incorrect behaviour on overflow.

If an experienced programmer like Steve Summitt can't get it right, then I
think we can say that fgets() is difficult to use.


The advice is correct (so far as it goes).
Of course it is not "bad" to call fgets() and discard the trailing '\n'.
What is necessary is to decide what to do when there is no trailing '\n',

So how do you determine if there is no trailing '\n', if it's been
discarded?


Because /you/ are the one who does the discarding, and you *remember* (or
rather, your code does).
and the level of complexity involved need not be large at all.

It depends what you mean. If you are comparing to some sort of analysis of
equations used in particle physics then, no, its not complicated. If you
mean that it adds substantial extra hassle to what should be a simple
process of getting a line from the user, then, yes, using fgets() properly
is complicated. You need to check the '\n', then discard the remainder of
the line, report an error message to the user (probably), and then loop to
get another line.


It's trivial to wrap this up into a function that dynamically resizes a
buffer; in fact, several of us here have done so (and published our code).

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #31
Malcolm <ma*****@55bank.freeserve.co.uk> spoke thus:
No its eccentric. Users generally won't accept command line programs unless
forced to use them. A GUI is generally far easier to use - I'm typing this
into a GUI newsreader.
If by "users" you mean the mass of people who use their computers to
surf the web, then sure. Many people who require more from their
machines than web surfing, however, find command line and text-based
utilities to be far more useful. I am typing this post in a
text-based newsreader (tin) running on a FreeBSD box in Texas while I
sit comfortably in an office in a suburb near Atlanta. I use the mutt
mail reader for my mail, and it is both much faster and much easier to
use than Outlook. Even the GUI utilities that I'm forced to use as a
part of my job (Borland's C++ compiler and make utility and Microsoft
Visual SourceSafe) I find to be much more effective when run from a
DOS prompt. I don't feel that I'm alone in these preferences with
respect to the professional computing community.
Well grep you would usually invoke with the name of the file to search.
"more" does use redirection, and it is a quirky thing to use - basically a
patch on the other utilities not being GUI. I have never had any reason to
use the other utilities mentioned.
Since when is more quirky? more myfile.txt - what could be simpler?
I suspect that you are missing out in a big way by disregarding
command line utilities, unless of course you *do* treat your computer
as a toy.
Just the vast majority of general-purpose computers in use today. Even jobs
that used to require a mainframe can now often be done on PCs. Things like
supermarket checkouts and airport information screens are often PCs
underneath.
The vast majority of medium-sized systems that aren't PCs are probably games
consoles. They don't use command lines either. Nor do mobile phones.


I agree insofar as the majority of computer users are not involved in
the programming and maintenance of the systems in question. Those who
are, as well as a number of flat-out enthusiasts, typically fall
squarely on the side of command-line utilities.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #32
On Sun, 14 Dec 2003 22:07:42 UTC, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:

"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message

Then we realise that we are more probably dealing with an eccentric.
Nobody preferring a console interface over a GUI is an eccentric,
but someone who knows about the power of command lines.

No its eccentric. Users generally won't accept command line programs unless
forced to use them. A GUI is generally far easier to use - I'm typing this
into a GUI newsreader.


We've seen you knows nothing about real computeing. Even as I type
this message in a GUI newsreader here are about 3 douzend console
programs active - whereas one of them does nothing but watching and
steering a GUI program for unattended process. Without active
stdin/stdout/stderr it would unable to do its work. This GUI program
runs 24h/7d unattended. It has its GUI only for the seldom case I like
to do some action manually or have a quick look at the logs. But the
latter would even so easy by a commandline program like less.

No, I don't use M$ software because M$ has proven itself to be
incompatible to anything - even to itself even in standard C.

My OS has the best possible GUI, yes - but even that is not enough for
lots of actions I have to do dayly. Nothing gives more flexibility in
work than a commandline interface - even as something gets done more
comfortable with the GUI.

A lot of standard command line utilities on a vast number of OSs are
filter programs. For example, you virtually can't do anything useful
on a typical *nix system without using stream filters, e.g. grep,
head, tail, sed, awk, gzip, more, cut, sort, ...

Well grep you would usually invoke with the name of the file to search.


No, not always.
"more" does use redirection, and it is a quirky thing to use - basically a
patch on the other utilities not being GUI.
Absolutely wrong. You don't know how to combine streams to get theyr
full power.
I have never had any reason to
use the other utilities mentioned.
Hm, as a person who knows nothing as using a GUI to click around to
combine predefined codesecuences to a new game you knows at least not
even how to program really. As a real programmer you would not even
use a GUI (even as you may use a GUI oriented editor) to build
programs instead clicking around. You should know how to use make, how
to pipe the compiler listing into your editors command window to steer
it to help you to fix your self programmed bugs.
Not all the world is a Wintel box. ;-)

Just the vast majority of general-purpose computers in use today.


is unable to run windows. It has not even another kind of GUI. The
advertizing of M$ is nothing than marketing for dumb users. Windows
GUI gets quickly unuseable when it comes to real facts and not only to
click, click.

Even jobs that used to require a mainframe can now often be done on PCs. Things like
supermarket checkouts and airport information screens are often PCs
underneath.
Right, but that is nowhere the mayority of computers. You've seen the
computers inside your car, your TV, your DVD player, your switch, your
router, your hard disk, your, monitor, your keyboard, your printer,
your camera, phones? There are more computers in your househeld, your
car, your car radio, trains, aircrafts, ships, motor cycles, boats,
mashines, .... as you would dream off.
Computer are conquering dayly more new fields you would never think.

There are computers with more power on a single board that 10 PCs who
have a comfortable user interfaces - but no keyboard and no screen, no
printer, no mouse, no GUI. PCs are only an absolute minority of the
wide fields where computeres running. GUIs are used soldom - but
commandline oriented user interfaces sofrequent as sand on the sea.
The vast majority of medium-sized systems that aren't PCs are probably games
consoles. They don't use command lines either. Nor do mobile phones.

But there more computers in only mobile telephones than game consoles.
There are more computers in factories, stores, mashines and so on than
PCs. Not each PC uses a GUI, many modern PC have never seen an monitor
attached, many PCs have never seen an hard disk attached, so many PCs
are running without GUI. Many PCs have a GUI only for the dumb user
who works with only the single program they know of - but when the
technican comes it kicks the GUI away to show the facts.

But most of all them above are programmed in C.

--
Tschau/Bye
Herbert

To buy eComStation 1.1 in germany visit http://www.ecomstation.de

Nov 14 '05 #33
On Sun, 14 Dec 2003 23:11:13 UTC, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:
And a note in passing to look up "Linux" sometime -- it looks
like it might be becoming more popular in both the commercial and
home markets. :)

It's only likely to succeed if it can protect the user from needing to use
the command shell. I can't use it since I need to run programs that only
work on Windows.

Ever when I have to use windows I have to use its console to get the
results I need quickly instead looking for looooong time on flying
things like folders or documents. Doing the same work on commandline
lets me get finished it long before the windows GUI ever has done the
first step.

Oh, yeah, on my OS I can use the GUI because it is more quickly, more
elegant, more solid. But even there it lefts administrative work done
better on commandline. That is because it costs more time to fire the
GUI program up and click around its GUI than simply start an (GUI)
editor from commandline giving it the file to edit as parameter. In
that case the GUI is for the dumb user who does not know what he is
doing and the flat file is for the expert - but the result would be
the same.

The dumb user will use a day to get it done by clicking though the GUI
- I use 5 minutes for the same by editing some lines in some
configuration files.

Oh, yes - windows is for dumb users only. Even an expert has too often
no chance to work quickly and more exact as the dumb wincrap GUI
allows.

--
Tschau/Bye
Herbert

To buy eComStation 1.1 in germany visit http://www.ecomstation.de

Nov 14 '05 #34
On Mon, 15 Dec 2003 06:44:30 UTC, Richard Heathfield
<do******@address.co.uk.invalid> wrote:
Using a non-GUI compiler, for a simple program it is of course easier to
type "cc foo.c" and everything will work.
Still in full agreement. Surely this can't last?


NOT using the GUI of the compiler still speeds up the build process
significantly. When you've learned how to use make, your text editor
(GUI - but full flagged for the use as developer tool) you would never
miss the GUI until you have to run your GUI program. Oh, yeah, a GUI
driven debug may help you significantly to debug your multithreaded
(non)GUI application.
Okay, so where in that lot do I use my routines to connect to, or disconnect
from, an SMTP server? Ah...

find dev -name \*.c | xargs grep SMTP[CD]
Using Windows "find" we can look for files or folders named "myprog.exe",
and the GUI leads us through it.
Yes, and it's *slow*. What's more, it's harder to use than a CLI (IMHO,
having tried both).


I use both for finding something - depending on the kind of work I
have to do. When you use a good GUI (windows ones is cramp) you ends
up in both cases exactly w3ith that you want. If you uses a good
command processor (not the DOS thing that comes with windoes - but an
intelligent one like sh or 4os2) and you have a brain then it would be
easy.
We can then double-click on the icons it
brings up to see what's in them.


Doesn't sound very scriptable to me.


Right - but often enough it would exactly fullify your needs. Else you
would use your commandline processor and its tools - when you're not
playing on windows.
However you do lose some flexibility -
you can't pipe to your own version of "sort" which handles numerical
values as numbers (so x2 is before x11), for instance.


That's not the only flexibility you lose.

<snip>
And a note in passing to look up "Linux" sometime -- it looks
like it might be becoming more popular in both the commercial and
home markets. :)

It's only likely to succeed if it can protect the user from needing to use
the command shell.


On the contrary, it has already succeeded. Incidentally, just like Windows,
it gives the user the *choice* of a powerful[1] command shell, or a weak
but pretty GUI.


And now we come to the point of truth. Use eComStation to get both - a
powerfull shell which you can exchange to others when you likes and a
powerfull GUI that can be extended easy by lots of frewware tools and
by yourself as a prograsmmer.
[1] The default Windows command shell is nowhere near as powerful as Linux's
various shells, IMHO, but hey, you can always use Cygwin.


No wounder it is the same as you had with DOS, nothing new, too less
tools, too high limited.
I can't use it since I need to run programs that only
work on Windows.


Why not do the world a favour and port them to Linux? :-)

Why not use eComStation and use them without porting? There is an open
source tool that migrates windows programms (NT, 2K, XP) on the fly
and lets them run seamless. There are already any usefull linux
commandline tools and shells ported to be native eComStation
applications, including apache, perl, php... and least but not last
anything you need to develop C programs.

--
Tschau/Bye
Herbert

To buy eComStation 1.1 in germany visit http://www.ecomstation.de

Nov 14 '05 #35
Malcolm wrote:
The real answer is that stdin is seldom used in real programs.

^^^^ ^^^^
The world is not only black and white, so it would be hard to give an
*real* answer. :-)

-Robert

--
Robert Bachmann _ _
Ro*************@rbdev.net |_) |_)
| \.|_).

Nov 14 '05 #36
On Sun, 14 Dec 2003 23:36:10 UTC, Mark McIntyre
<ma**********@spamcop.net> wrote:
Pray tell me, how /do/ you send an text without typing?


Switch your microphone on, start up voice type, navigate your GUY by
speaking to your computer, let it open your preferred word
processor/mail program and dictate the text and formatting, order it
to print the document, read it, navigate with voice inside the text,
command the correctios, command it to save the document or to mail it
to its destination.

It can be done since 1996.

--
Tschau/Bye
Herbert

To buy eComStation 1.1 in germany visit http://www.ecomstation.de

Nov 14 '05 #37
On Mon, 15 Dec 2003 05:46:17 UTC, "Mac" <fo*@bar.net> wrote:
No its eccentric. Users generally won't accept command line programs unless
forced to use them. A GUI is generally far easier to use - I'm typing this
into a GUI newsreader.


Actually system administrators hate GUI's because they (sysadmins)
sometimes have to do the same thing over and over to many computers, and
what they really want is a way to script the action, while still allowing
a certain number of intelligent variables.

This is why Microsoft is now working on the shell to beat all shells.
(We'll se if they succeed, but they have recognized the deficit and are
trying to fix it.)


Microsoft was saying the same more than 10 years ago. It repeats that
every year new but was never able to get it right. It had the chance
to come nearly that what OS/2 2.0 had done 11 years ago - but failed
even with XP to come nearly on that what OS/2 had brought.
The vast majority of medium-sized systems that aren't PCs are probably games
consoles. They don't use command lines either. Nor do mobile phones.


Yeah, but they are not wintel boxes, either, which is the claim you seem
to be trying to contradict.

Anyway, don't forget about routers and access points and so on. Behind the
scenes, they absolutely use command lines.

And don't forget about all the embedded systems that don't really have a
user interface at all. Processors in cars, for example.

Besides, a lot of people like command lines. I'm one of them. ;-)


Me too - but my system gives me the best of both worlds at once. I use
the GUI extensively - but commandline whenever it is more effective.

Currently I use a system with 512 MB RAM, 4 GUI applications and 8
command windows active beside some desktop objects spreaded over 4
virtual desktops - and have about 256 MB RAM free. No, its not
windows, its not linux - but a PC where both are installed and
bootable when I may need them.

--
Tschau/Bye
Herbert

To buy eComStation 1.1 in germany visit http://www.ecomstation.de

Nov 14 '05 #38

"The Real OS/2 Guy" <os****@pc-rosenau.de> wrote in message
We've seen you knows nothing about real computeing.
[ snip ]
No, I don't use M$ software because M$ has proven itself to be
incompatible to anything - even to itself even in standard C.

I rest my case.
Nov 14 '05 #39

<ph**************@ipal.net> wrote in message

Sure games are big, and there's money in games. But the real world is > no game. You better hope the game markets keeps going as I feel you could not make it in any other field.

What we're finding is that games are taking over a lot of serious
applications. Flight simulators are an obvious example. 3d graphics are
increasingly being used for other non-games, for instance to produce
architectural models. Then games and mobile phone apps are beginning to
merge. Finally, millions of consumers have a games console as their only
general-purpose computer.

However people aren't going to stop playing video games, and we have a fun
environment in which to work.

Nov 14 '05 #40
Mac
On Sun, 14 Dec 2003 22:07:42 +0000, Malcolm wrote:

"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message
>
> Then we realise that we are more probably dealing with an eccentric.
Nobody preferring a console interface over a GUI is an eccentric,
but someone who knows about the power of command lines.

No its eccentric. Users generally won't accept command line programs unless
forced to use them. A GUI is generally far easier to use - I'm typing this
into a GUI newsreader.


Actually system administrators hate GUI's because they (sysadmins)
sometimes have to do the same thing over and over to many computers, and
what they really want is a way to script the action, while still allowing
a certain number of intelligent variables.

This is why Microsoft is now working on the shell to beat all shells.
(We'll se if they succeed, but they have recognized the deficit and are
trying to fix it.)

A lot of standard command line utilities on a vast number of OSs are
filter programs. For example, you virtually can't do anything useful
on a typical *nix system without using stream filters, e.g. grep,
head, tail, sed, awk, gzip, more, cut, sort, ...

Well grep you would usually invoke with the name of the file to search.
"more" does use redirection, and it is a quirky thing to use - basically a
patch on the other utilities not being GUI. I have never had any reason to
use the other utilities mentioned.


Well, you should have enough humility and wisdom to realize that you are
only one person, and your experiences do not represent the full spectrum
of what's out there.

Not all the world is a Wintel box. ;-)

Just the vast majority of general-purpose computers in use today. Even jobs
that used to require a mainframe can now often be done on PCs. Things like
supermarket checkouts and airport information screens are often PCs
underneath.


You seem to be ignoring all the embedded systems. We seem to be moving
towards a world where every single product which consumes power has a
microprocessor in it. Those processors are mostly not running microsoft
software or GUI's, properly speaking.
The vast majority of medium-sized systems that aren't PCs are probably games
consoles. They don't use command lines either. Nor do mobile phones.


Yeah, but they are not wintel boxes, either, which is the claim you seem
to be trying to contradict.

Anyway, don't forget about routers and access points and so on. Behind the
scenes, they absolutely use command lines.

And don't forget about all the embedded systems that don't really have a
user interface at all. Processors in cars, for example.

Besides, a lot of people like command lines. I'm one of them. ;-)

Mac

Nov 14 '05 #41
On Mon, 15 Dec 2003 17:58:49 +0000 (UTC), in comp.lang.c , "The Real
OS/2 Guy" <os****@pc-rosenau.de> wrote:
On Mon, 15 Dec 2003 05:46:17 UTC, "Mac" <fo*@bar.net> wrote:
This is why Microsoft is now working on the shell to beat all shells.
(We'll se if they succeed, but they have recognized the deficit and are
trying to fix it.)


Microsoft was saying the same more than 10 years ago. It repeats that
every year new but was never able to get it right.


Which is absurd, given that several other companies sell very good
shells indeed.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #42
On Mon, 15 Dec 2003 17:42:44 +0000 (UTC), in comp.lang.c , "The Real
OS/2 Guy" <os****@pc-rosenau.de> wrote:
On Sun, 14 Dec 2003 23:36:10 UTC, Mark McIntyre
<ma**********@spamcop.net> wrote:
Pray tell me, how /do/ you send an text without typing?
Switch your microphone on, start up voice type, navigate your GUY by
speaking to your computer,


erm, we're using a mobile phone here....
let it open your preferred word
processor/mail program and dictate the text and formatting,
on a /phone/ ?
order it
to print the document, read it, navigate with voice inside the text,
command the correctios, command it to save the document or to mail it
to its destination. It can be done since 1996.


Yes, I've had speech recognition on my PC since about then. Pile of
junk.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #43
Malcolm wrote:
I rest my case.


Is your being a troll now official, then?

Nov 14 '05 #44
On Mon, 15 Dec 2003 18:29:28 -0000
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

<ph**************@ipal.net> wrote in message

Sure games are big, and there's money in games. But the real world
is no game. You better hope the game markets keeps going as I feel
you could not make it in any other field.
What we're finding is that games are taking over a lot of serious
applications. Flight simulators are an obvious example.


The last I checked (admittedly a good few years ago) the commercial
flight simulators were *very* different beasts to the flight sim games.
For a start, they used several computers for one flight simulator,
secondly they did not have a GUI, all the interfacing being via real
aircraft controls
3d graphics are
increasingly being used for other non-games, for instance to produce
architectural models.
I would be surprised if 3D CAD did not predate 3D games.
Then games and mobile phone apps are beginning
to merge. Finally, millions of consumers have a games console as their
only general-purpose computer.
A games console is not a general purpose computer, it is a very heavily
targeted computer.
However people aren't going to stop playing video games, and we have a
fun environment in which to work.


However most computers will continue to be without GUI interfaces
because most will continue to have no display at all.

To get back to whether there is much done with just stdin/stdout/stderr
interfaces, on computers used for serious work (such as running the
financial applications for some big companies) there are a host of
administrative tasks performed by automation scripts which rely on
programs accepting input from stdin and sending output to stdout. Such
input/output streams being redirected and, when appropriate, the output
being fed in to the input stream of a command line mail client to let
the administrator know there is a problem.

Also command line tools are far better (so the support staff tell me)
when you have to log on to a machine across the internet or a dial up
and fix things.

These tasks may not be what the majority of PC users do, but they still
account for a lot of the real work done on computers.
--
Flash Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Nov 14 '05 #45
On Mon, 15 Dec 2003 23:17:17 UTC, Mark McIntyre
<ma**********@spamcop.net> wrote:
On Mon, 15 Dec 2003 17:42:44 +0000 (UTC), in comp.lang.c , "The Real
OS/2 Guy" <os****@pc-rosenau.de> wrote:
On Sun, 14 Dec 2003 23:36:10 UTC, Mark McIntyre
<ma**********@spamcop.net> wrote:
Pray tell me, how /do/ you send an text without typing?
Switch your microphone on, start up voice type, navigate your GUY by
speaking to your computer,


erm, we're using a mobile phone here....


Sure that your soundcard ends in your mobile phone instead of
loudspeakers?
let it open your preferred word
processor/mail program and dictate the text and formatting,
on a /phone/ ?


On a microphone. A think that get connected into a soundcard.
order it
to print the document, read it, navigate with voice inside the text,
command the correctios, command it to save the document or to mail it
to its destination.

It can be done since 1996.


Yes, I've had speech recognition on my PC since about then. Pile of
junk.

I don't speak about wincrap.

--
Tschau/Bye
Herbert

To buy eComStation 1.1 in germany visit http://www.ecomstation.de

Nov 14 '05 #46
Flash Gordon <sp**@flash-gordon.me.uk> spoke thus:
Also command line tools are far better (so the support staff tell me)
when you have to log on to a machine across the internet or a dial up
and fix things.


Just to elaborate: Which do you think is faster - accessing a
computer's desktop graphically via PCAnywhere or some such
application, or accessing a computer via ssh on the command line?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #47

"Grumble" <in*****@kma.eu.org> wrote in message

Malcolm wrote:
I rest my case.


Is your being a troll now official, then?

We all like a joke at the expense of Microsoft. However anyone who takes
these jokes seriously has disqualified himself as someone who knows
something about the world of computers.

Nov 14 '05 #48
Something that calls itself Grumble wrote:
Malcolm wrote:
I rest my case.


Is your being a troll now official, then?


1. troll handle: Grumble
2. forged email address: in*****@kma.eu.org
3. attempt to provoke an emotional response: <above>
4. off topic ad hominem attack: against Malcolm

Please don't feed the troll.

Nov 14 '05 #49
"E. Robert Tisdale" wrote:
Please don't feed the troll.


As always, it takes one to know one.


Brian Rodenborn
Nov 14 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

39
by: Teh Charleh | last post by:
OK I have 2 similar programmes, why does the first one work and the second does not? Basically the problem is that the program seems to ignore the gets call if it comes after a scanf call. Please...
7
by: sajjanharudit | last post by:
Can anyone explain me what is happening in the following code: #include<stdio.h> int main() { int i,j; scanf("%d %d" + scanf("%d %d",&i,&j)); printf("%d %d\n"); }
51
by: moosdau | last post by:
my code: do { printf("please input the dividend and the divisor.\n"); if(!scanf("%d%d",&dend,&dor)) { temp1=1; fflush(stdin); } else
280
by: jacob navia | last post by:
In the discussion group comp.std.c Mr Gwyn wrote: < quote > .... gets has been declared an obsolescent feature and deprecated, as a direct result of my submitting a DR about it (which...
104
by: jayapal | last post by:
Hi all, Whenever I use the gets() function, the gnu c compiler gives a warning that it is dangerous to use gets(). why...? regards, jayapal.
19
by: subratasinha2006 | last post by:
I can not accept a string (without space) of length more than 127 whatever I do.. Entry is restricted by 127 characters. I have declared an array of size more than 200. or I have used...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.