december_beauty wrote On 09/30/05 12:13,:
> I am writing a program which
> a) accepts a command as a string
> b) breaks the string into separate arguements
> Eg: string : ls -l
> argv[0]=ls arg[1]=-l
If you're doing what I think you're doing, you probably
want argv[2[=NULL as well.
> When I read the string using gets, it works fine. But when I use the
> read(), it doesn't work.
First, see Question 12.23 in the comp.lang.c Frequently
Asked Questions (FAQ)
http://www.eskimo.com/~scs/C-faq/top.html
to learn why gets() is a bad idea, and why you should NEVER
use gets() for input from a source you don't control.
Second, there is no read() function in the Standard C
library.
Third, "it doesn't work" isn't a useful description of
your problem. It's about as helpful as my advice "Fix the
bug in your code."
> I know how to parse the string and break them into individual
> arguement, I am not happy with what I have coded it. Is there a
> solution for this on the internet?
A solution for what? For your unhappiness? You haven't
said why you're sad, nor what makes you happy, so I can't
offer any recommendation.
> c) I need to exit when it presses ctrl-D. I don't know how to catch
> ctrl-D. I tried a few things like, checking the first character of
> the string with ascii value of ctrl-D, it's not working.
> PLEASE HELP..
Keyboards and similar "interactive input" devices are
often given special treatment by operating systems, with the
result that what the program reads is not a simple record of
the keys the user pressed. This is usually a good thing: if
the user presses `l s - BS SPC - l ENTER' the program reads
"ls -l\n" and doesn't need to worry about all that intra-line
editing or about what code the ENTER key generates. Also,
most operating systems don't even generate characters for
some key combinations, instead treating them as "control
signals" of one kind or another.
On many systems, control-D is one such special keystroke.
Instead of generating a character that the program can read,
it tells the program that there is no more keyboard input to
be read: it synthesizes an "end-of-file" indication for a
device that inherently has no such thing. If you're using
such a system, there may be no way (or no "normal" way) to
read a control-D: instead, the attempt to read will yield
end-of-file. Perhaps the solution to your problem is not to
check for control-D at all, but to check for EOF.
(Note: Not all systems treat control-D this way. Some do
a similar thing with control-Z, and I've also seen control-A
used for the purpose. Some systems "ordinarly" use control-D
but can be adjusted to use some other key combination instead.)
--
Similar Threads
