Command line arguments

[Les Cargill]

I'm pretty sure this example doesn't demonstrate what you think it does.
(I know what it demonstrates, but I can't be sure what you intended.)

I mainly intended to show that they are different, nothing more
specific. Turned out to be a triumph of brevity over content

 

[Joe Pfeiffer]

On Windows, characters such as |, < and > have special meaning meaning to
the 'shell', so the first command would see:

-lt $(find . -name data\*)

and the next -$1, which I guess has special meaning in Unix, perhaps like %1
in Windows BAT files. But this is starting to get into scripting now. A few
escapes are acceptable (I was going to say inescapable), and sometimes there
is nothing the invoked program can do with them anyway.

However, to add "*" to the end of \windows\system32\, and turn that one
parameter, into 2745 parameters, is something that is in a class of its own.

(And imagine that all you'd intended doing with that parameter was to
write it out again as a part of an argument to system(). Or perhaps
changing a *.c spec to a *.o one, which suddenly becomes a bit more
difficult.)

Basically, you've got experience with Windows, so you're uncomfortable
with the different approach taken by Unix-ish shells. That's fine; my
few uncomfortable excursions into Windows leave me feeling much the same
though in the opposite direction.

If you're going to write your program to run under Linux, you're simply
going to have to get used to the Unix-ish way of doing things.
Likewise, if I were to ever write a Windows program, I'd have to retrain
a lot of my expectations.

We simply have to be flexible enough to work in the environment we find
ourselves, and not try to turn it into what we're used to.

 

[BartC]

On 01/11/2013 06:46 PM, BartC wrote:
...

Your first message on this thread implies that you never knew about this
feature until yesterday, which implies that you must be very new to
unix-like systems.

I was using Windows, and the problem manifested itself under Windows. I
assumed it was feature of the C runtime, and that it would be the same under
Linux. It turns out it *was* done by the C runtime in this case.

But I've also been using the C runtime for years in the background of other
projects, and I'd never seen it behave that way. So it was specific to gcc
which I've switched to recently.

At the moment, your impression of this feature is
based primarily upon the fact that it differs from what you're used to.
I recommend getting the equivalent of at least several months full-time
experience with unix-like environments before making a judgment about
the value of this feature.

I will, as soon as some of my own tools are ported over. (I'm struggling
getting even the keyboard to behave itself at the moment, trying to get
things to work that had been sorted out years ago under Windows. Do other
people use ncurses, or do they have to delve deeper into the system to get
even basic shift+ctrl combos working?)

The wildcard problem was on a utility that is only meaningful under Windows,
so is not a huge problem. But something I have to keep in mind, and steer
well clear of in future.

 

[James Kuyper]

I was using Windows, and the problem manifested itself under Windows. I
assumed it was feature of the C runtime, and that it would be the same under
Linux. It turns out it *was* done by the C runtime in this case.

Sorry about that. Some of the things that you said suggested that fact,
but I hadn't noticed.

 

[James Kuyper]

I was using Windows, and the problem manifested itself under Windows. I
assumed it was feature of the C runtime, and that it would be the same under
Linux. It turns out it *was* done by the C runtime in this case.

Sorry about that. Some of the things that you said suggested that fact,
but I hadn't noticed.

 

[Joe Pfeiffer]

I will, as soon as some of my own tools are ported over. (I'm
struggling getting even the keyboard to behave itself at the moment,
trying to get things to work that had been sorted out years ago under
Windows. Do other people use ncurses, or do they have to delve deeper
into the system to get even basic shift+ctrl combos working?)

If all you're doing is raw input, look into putting stdin into 'raw'
mode with the tcsetattr() call. If you're going to be doing any cursor
manipulation, use ncurses.

 

[Keith Thompson]

Well, I suppose "the unix shell" does have some meaning, which would
be the (original) Bourne shell, back from when there was only one.

The POSIX standard defines a set of functionality for "the" shell.
Bourne-derived shells generally attempt to conform to that standard,
while adding their own extensions. csh and tcsh don't.

And /bin/sh (which can be the Bourne shell or someting else) has a
special status; it's what system() uses to process its string argument.

[...]

 

[Keith Thompson]

This is a *shell* behavior - of bash, I think ( and perhaps others ) -
so something like invoking the program with csh might be helpful.

user@user-desktop:~$ echo *.c
o.c
user@user-desktop:~$ csh echo *.c
echo: No such file or directory.
user@user-desktop:~$

[...]

That causes csh to attempt to execute a file named "echo" as a shell
script, passing it the expansion of *.c as command-line arguments.

csh -c 'echo *.c' does what you're trying to do, but csh expands
wildcards in a way very similar to sh/ksh/bash, the main difference
being what happens if there are no matches.

 

[Keith Thompson]

I was using Windows, and the problem manifested itself under Windows. I
assumed it was feature of the C runtime, and that it would be the same under
Linux. It turns out it *was* done by the C runtime in this case.

So a program compiled on and for Windows with gcc (MinGW?) implicitly
invokes some C runtime routine that expand wildcards that appear
on the command line?

That's consistent with what I'm seeing. On Windows 7, a C program
compiled with MinGW and invoked with *.c on the command line sees a
list of file names as separate elements of the argv array; a similar
program compiled with MS Visual C++ 2010 sees a single argument,
the string "*.c".

The difference in behavior does seem a little odd. An alternative
would have been for MinGW to fit in with the usual Windows behavior,
where individual programs are responsible for expanding (or not
expanding) wildcards. I think the idea behind MinGW is to provide
a minimal POSIX-like environment under Windows, not to provide a
gcc compiler integrated into the Windows environment. (There are
likely options to make it do the latter; I haven't looked into it.)

But I've also been using the C runtime for years in the background of other
projects, and I'd never seen it behave that way. So it was specific to gcc
which I've switched to recently.

The C runtime library is not part of gcc; gcc is just the compiler
(it can also invoke the linker). Apparently the behavior you're
seeing is the result of the way the MinGW developers have chosen
to integrate the gcc compiler, the Microsoft C runtime library,
and whatever other components they've added.

Since you seem to be happier with the Windows behavior (where
programs are responsible for their own wildcard handling) than
with the POSIX behavior (where wildcards are expanded before main()
starts running), why are you using MinGW in the first place?

If you want to write programs that run on POSIX systems (Linux,
Unix, Cygwin, etc.), I advise you *not* to try to override the way
wildcards are expanded. Even if you managed to do it, the resulting
behavior would be extremely counterintuitive to your users, who are
likely to be as uncomfortable with wildcards *not* being pre-expanded
as you are with them being pre-expanded. If I have a copy of your
program and I need to pass the string "*.c" to it as an argument,
I know exactly how to do it. Think about what behavior your users
are going to expect, not just what you personally prefer.

 

[BartC]

"BartC" <[email protected]> writes:

Since you seem to be happier with the Windows behavior (where
programs are responsible for their own wildcard handling) than
with the POSIX behavior (where wildcards are expanded before main()
starts running), why are you using MinGW in the first place?

It's just a C compiler that works with Windows; I don't care where it
originated from. It's got some extensions I need, a good optimiser, and I
thought I'd have better luck running the same programs under Linux with
little change. (And in fact an interpreter project from a PC did work first
time.)

I didn't know about the wildcard expansion thing.

If you want to write programs that run on POSIX systems (Linux,
Unix, Cygwin, etc.), I advise you *not* to try to override the way
wildcards are expanded.

I probably won't bother now. As someone suggested, I'll probably end up
creating my own 'shell' (a form of IDE), but running under what the OS
provides rather than replacing it.

 

[glen herrmannsfeldt]

It's just a C compiler that works with Windows; I don't care where it
originated from. It's got some extensions I need, a good optimiser, and I
thought I'd have better luck running the same programs under Linux with
little change. (And in fact an interpreter project from a PC did work first
time.)

I didn't know about the wildcard expansion thing.

There was a wildcard expansion routine at least back to MSC 6.0 in
about 1989. You link in an extra library routine to use it, otherwise
you didn't have it. (Possibly it was 7.0, but I believe 6.0.)

-- glen

 

[Shao Miller]

I will, as soon as some of my own tools are ported over. (I'm struggling
getting even the keyboard to behave itself at the moment, trying to get
things to work that had been sorted out years ago under Windows. Do
other people use ncurses, or do they have to delve deeper into the
system to get even basic shift+ctrl combos working?)

The wildcard problem was on a utility that is only meaningful under
Windows, so is not a huge problem. But something I have to keep in mind,
and steer well clear of in future.

Do you mind if I ask: Which version of MinGW are you using? I believe
that wildcard expansion is turned off by default, for the mingw64
toolchain. I usually use this toolchain for compiling Windows programs
under Linux.

 

[BartC]

On 1/12/2013 07:06, BartC wrote:

Do you mind if I ask: Which version of MinGW are you using? I believe
that wildcard expansion is turned off by default, for the mingw64
toolchain. I usually use this toolchain for compiling Windows programs
under Linux.

Its 4.5.0, generating 32-bit output.

 

[Alan Curry]

I will, as soon as some of my own tools are ported over. (I'm struggling
getting even the keyboard to behave itself at the moment, trying to get
things to work that had been sorted out years ago under Windows. Do other
people use ncurses, or do they have to delve deeper into the system to get
even basic shift+ctrl combos working?)

I assure you, the Linux console and xterm are more accurate emulations of the
VT100 than anything you ever saw in Windows (unless you had a Windows xterm)

The terminal interface is based on streams of characters, corresponding to
stdin and stdout/stderr. The format of these streams is usually ASCII or a
superset of ASCII like ISO8859-x or UTF-8. Where in any of those character
sets do you find "shift+ctrl combos"?

xterm reports modifiers as part of the escape sequence for control keys, so
you can distinguish F1 from Ctrl+F1 from Shift+Ctrl+F1 (see ctlseqs.txt for
details) but not for normal keys. If you think Shift+Ctrl+S should send
something different from Ctrl+S, you are thinking very non-ASCII-compatible.
Those both need to be ASCII code 19 or we'll all go insane.

Raw keyboard access is possible on the console (see KDSKBMODE in
console_ioctl(4)), but not a good idea for any program that wants to appear
even slightly normal. It's a complete keyboard takeover. VT switching will
not work, leaving the user trapped unless you detect the Alt+Fn key
combinations and handle them yourself. Very rude.

[n]curses only attempts to organize the common features of the traditional
terminal types in a coherent way, and raw keyboard mode isn't one of them.

When your input scheme isn't ASCII or UTF-8, you need a more ambitious
library than curses. Like SDL, or an X11 widget library (Xt+Xaw/Xm, tk,
wxWidgets, gtk, etc.) or raw Xlib.

 

[Tim Rentsch]

[snip] If you say it's just what was typed, a program would need a
complex parser just to work out what it's first argument is! [snip]

^^^^

Oh no! Not you too.... :/

 

[Shao Miller]

[snip] If you say it's just what was typed, a program would need a
complex parser just to work out what it's first argument is! [snip]

^^^^

Oh no! Not you too.... :/

I read the same text, and had precisely the same exclamation.

There is an article about some history of "it's" versus "its" which
helps me to feel a little looser about it, these days. I don't know how
authoritative it should be considered.

http://www.word-detective.com/back-d.html#its

 

[Ben Bacarisse]

[snip] If you say it's just what was typed, a program would need a
complex parser just to work out what it's first argument is! [snip]

^^^^
Oh no! Not you too.... :/

Me too what? The existence of typos in my posts can't be news -- I must
have just about the highest typo rate of anyone here!

If you meant to imply that a typo indicates a lack of knowledge, then I
must retort "oh no, not you too?" because I've got very used to that
particular canard over the years!

 

[Geoff]

There was a wildcard expansion routine at least back to MSC 6.0 in
about 1989. You link in an extra library routine to use it, otherwise
you didn't have it. (Possibly it was 7.0, but I believe 6.0.)

-- glen

The relevant functions are _findfirst, _findnext and _findclose. They
are defined in <io.h> but there is no special library linkage needed.
They exist in kernel32.lib which is linked by default in the VC 6.0
and higher IDE. I don't remember if it existed prior to VC 6.0 but it
probably did, I have a documented program that used it with QuickC 2.0
in 1991.

 

[BartC]

I assure you, the Linux console and xterm are more accurate emulations of
the
VT100 than anything you ever saw in Windows (unless you had a Windows
xterm)

This is where you lose me. I'm not interested in emulation of any sort of
terminal. I just want to read keys from my keyboard; how difficult can it
be?

I understand that with standard line input via C's getchar() and so on, the
OS or the library will take care of basic line-editing; that's fine.

But moving just one step beyond that, in order to implement a console-based
editor for example, seems to have been made extraordinarily difficult for
some reason!

The terminal interface is based on streams of characters, corresponding to
stdin and stdout/stderr. The format of these streams is usually ASCII or a
superset of ASCII like ISO8859-x or UTF-8. Where in any of those character
sets do you find "shift+ctrl combos"?

The keyboard handling I want needs two kinds of key presses. Printable keys,
and control keys. They don't need to share the same code-space. I don't
expect it to work with stdin as I said above, and I don't see the need to
have to encode everything as a serial stream of ASCII codes either.

xterm reports modifiers as part of the escape sequence for control keys,
so
you can distinguish F1 from Ctrl+F1 from Shift+Ctrl+F1

I'm sorry I don't know what xterm is. And I don't really want to know! Isn't
there just a language or OS function to just tell me what the next key event
is?!

[n]curses only attempts to organize the common features of the traditional
terminal types in a coherent way, and raw keyboard mode isn't one of them.

They must use a different meaning for 'coherent' than is generally
understood! The special key codes returned by ncurses are all over the
place, and capabilities seem to vary wildly between Windows and Debian for
example (the latter ignores most shift combinations).

When your input scheme isn't ASCII or UTF-8, you need a more ambitious
library than curses. Like SDL, or an X11 widget library (Xt+Xaw/Xm, tk,
wxWidgets, gtk, etc.) or raw Xlib.

Help! It sounds so complicated that I may have to forget the whole thing,
and just make my editors etc work with the minimum set of keys that are
certain to be available. (However, the SDL looks intriguing..)

 

[glen herrmannsfeldt]

(snip, someone wrote)
(snip, then I wrote)

The relevant functions are _findfirst, _findnext and _findclose. They
are defined in <io.h> but there is no special library linkage needed.
They exist in kernel32.lib which is linked by default in the VC 6.0
and higher IDE. I don't remember if it existed prior to VC 6.0 but it
probably did, I have a documented program that used it with QuickC 2.0
in 1991.

Well, there is that, too, but also a routine to automatically expand
wildcards before calling main(argc,argv). I believe back to MSC6.0
(that is, the non-visual C compiler) and about the time of QuickC.

If I remember right, you link in one extra .OBJ file and it does
everything else.

-- glen