Contrary to popular belief and many people's wishes, this is not
a C-related question. (Nor are closely-related questions
concerning the echo of keyboard input.) The delivery of
characters from a "keyboard" to a C program is a function of the
operating system in use, and has not been standardized by the C
language. Some versions of curses have a cbreak() function
which does what you want. If you're specifically trying to read
a short password without echo, you might try
ioctl to play with the terminal driver modes (
RAW under "classic" versions;
c_cc[VTIME] under System V or Posix systems). Under MS-DOS, use
getch(). Under VMS, try the Screen Management (
or curses, or issue low-level
$QIO's with the
IO$M_NOECHO) function codes to ask for one character at
a time. Under other operating systems, you're on your own.
Beware that some operating systems make this sort of thing
impossible, because character collection into input lines is
done by peripheral processors not under direct control of the
CPU running your program.
Operating system specific questions are not appropriate for comp.lang.c . Many common questions are answered in frequently-asked questions postings in such groups as comp.unix.questions and comp.os.msdos.programmer . Note that the answers are often not unique even across different variants of a system; bear in mind when answering system-specific questions that the answer that applies to your system may not apply to everyone else's.
References: PCS Sec. 10 pp. 128-9, Sec. 10.1 pp. 130-1.
These, too, are entirely operating-system-specific. Some
versions of curses have a
nodelay() function. Depending on your
system, you may also be able to use "nonblocking I/O", or a
system call named "select", or the
rdchk(), or the
O_NDELAY option to
Such things depend on the terminal type (or display) you're
using. You will have to use a library such as
curses, or some system-specific routines, to perform these
Consult your system documentation, or ask on an appropriate system-specific newsgroup (but check its FAQ list first). Mouse handling is completely different under the X window system, MS- DOS, Macintosh, and probably every other system.
argv may contain all or part of the pathname, or it may
contain nothing. You may be able to duplicate the command
language interpreter's search path logic to locate the
executable if the name in
argv is present but incomplete.
However, there is no guaranteed or portable solution.
In general, it cannot. Different operating systems implement name/value functionality similar to the Unix environment in different ways. Whether the "environment" can be usefully altered by a running program, and if so, how, is system-dependent.
Under Unix, a process can modify its own environment (some
putenv() functions to do this),
and the modified environment is usually passed on to any child
processes, but it is not propagated back to the parent
On Unix-like systems, you can try the
access() routine, although it's got a few
problems. (It isn't atomic with respect to the following
action, and can have anomalies if used in setuid programs.)
Another option (perhaps preferable) is to call
stat() on the file. Otherwise, the only
guaranteed and portable way to test for file existence is to try
opening the file (which doesn't help if you're trying to avoid
overwriting an existing file, unless you've got something like the
open option available).
If the "size of a file" is the number of characters you'll be
able to read from it in C, it is in general impossible to
determine this number in advance. Under Unix, the
will give you an exact answer, and several other systems supply
stat which will give an approximate answer. You can
fseek to the end and then use
ftell, but this usage is
nonportable (it gives you an accurate answer only under Unix,
and otherwise a quasi-accurate answer only for ANSI C "binary"
files). Some systems provide routines called
Are you sure you have to determine the file's size in advance? Since the most accurate way of determining the size of a file as a C program will see it is to open the file and read it, perhaps you can rearrange the code to learn the size as it reads.
BSD systems provide
ftruncate(), several others supply
and a few may provide a (possibly undocumented)
F_FREESP. Under MS-DOS, you can sometimes use
write(fd, "", 0).
However, there is no truly portable solution.
Unfortunately, there is no portable way. V7 Unix, and derived
systems, provided a fairly useful
ftime() routine with
resolution up to a millisecond, but it has disappeared from
System V and Posix. Other routines you might look for on your
poll() calls (if
available) can be pressed into service to implement simple
delays. On MS-DOS machines, it is possible to reprogram the
system timer and timer interrupts.
You want a dynamic linker and/or loader. It is possible to
malloc some space and read in object files, but you have to know
an awful lot about object file formats, relocation, etc. Under
BSD Unix, you could use
ld -A to do the linking for
you. Many (most?) versions of SunOS and System V have the
library which allows object files to be dynamically loaded.
There is also a GNU package called "dld". See also question
References: K&R II Sec. B6 p. 253; ANSI Sec. 184.108.40.206; H&S Sec. 21.2; PCS Sec. 11 p. 179;
Unix and some other systems provide a
popen() routine, which
sets up a
stdio stream on a pipe connected to the process
running a command, so that the output can be read (or the input
supplied). Alternately, invoke the command simply (see
question 16.12) in such a way that
it writes its output to a file, then open and read that file.
References: PCS Sec. 11 p. 169 .
See if you can use the
readdir() routines, which
are available on most Unix systems. Implementations also exist
for MS-DOS, VMS, and other systems. (MS-DOS also has
FINDNEXT routines which do essentially the same thing.)
It's system-dependent. Under Unix, you typically open, read,
and write a device in
/dev, and use the facilities of the
terminal driver to adjust its characteristics. Under MS-DOS,
you can either use some primitive BIOS interrupts, or (if you
require decent performance) one of any number of interrupt-driven
serial I/O packages.