Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Command line arguments

Reply
Thread Tools

Command line arguments

 
 
James Kuyper
Guest
Posts: n/a
 
      01-14-2013
On 01/13/2013 08:34 PM, Alan Curry wrote:
> In article <V6GIs.2274$(E-Mail Removed)7>, BartC <(E-Mail Removed)> wrote:

....
>> o Being able to know what keys have been pressed on my keyboard, including
>> the various shifts that all computer keyboards have had for decades. I don't
>> consider Ctrl+Home to be that esoteric. (What key combo do *you* use to get
>> to the beginning of a file? I bet it involves a shift, ctrl or alt key!)

>
> In the editor "vim", the command for "move to beginning of file" is gg.
> No shifting necessary! The classic vi command is 1G (i.e. Goto line 1),
> which does involve a shift key to generate the G, but the editor doesn't
> *know* that you used the shift key. Typing "1g" with caps-lock on would
> do the same thing. The editor can't tell the difference. It only knows
> that it received an uppercase G (ASCII code 71).
>
> Have you ever used a unix text editor before deciding you needed to make
> a new one?


Bart appears to be a follower of the NIH (Not Invented Here) principle.
He wants to reinvent everything himself; nothing designed by anyone else
is good enough to be used without modification.
--
James Kuyper
 
Reply With Quote
 
 
 
 
JohnF
Guest
Posts: n/a
 
      01-14-2013
Phil Carmody <(E-Mail Removed)> wrote:
> JohnF <(E-Mail Removed)> writes:
>> BruceS <(E-Mail Removed)> wrote:
>> > <<snip>> From a terminal (in Linux), type 'echo *', and it
>> > echos a list of the files in that directory. Enclose in quotes (as
>> > suggested elsethread), and type 'echo "*"', and get a single asterix.

>>
>> No longer a C question, per se, but bash's behavior (at least on
>> my slackware 14.0 box) is a bit more complicated than suggested above.
>> echo * echoes a list of all files as stated
>> echo t*.c echoes test.c because that's the only such file in my /home
>> echo a*.c echoes a*.c apparently because there are no a*.c files at all
>> So if there are no matches, it reverts to echoing the string rather
>> than emitting an error like ls would. Is there a more general rule
>> behind that behavior?

>
> As always, man bash(1). When there, /nullglob and /shopt.
> e.g.:
> """
> $ echo *.xxx
> *.xxx
> $ shopt -s nullglob
> $ echo *.xxx
>
> """
> Phil


Thanks for the info, Phil. Yeah, that answers my questions,
and failglob gives yet another option (similar to ls).
Wasn't aware of shopt, and hadn't read bash's long manpage,
but knowing where to look makes reading it more man(ageable).
Still doesn't completely simplify C programming, however,
where I'm often picking up command-line args, and sometimes
passing them on to popen() in a constructed command string.
Might still be hard to strictly control any unexpected
globbing behavior, e.g., on strings containing an * that's
not intended as a (wildcard) file specification at all.
--
John Forkosh ( mailto: http://www.velocityreviews.com/forums/(E-Mail Removed) where j=john and f=forkosh )
 
Reply With Quote
 
 
 
 
Sjouke Burry
Guest
Posts: n/a
 
      01-14-2013
Geoff <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> On Sun, 13 Jan 2013 01:51:47 +0000 (UTC), glen herrmannsfeldt
> <(E-Mail Removed)> wrote:
>
>>>>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.)

>>
>>> 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.

>
> In that case I believe you might be referring to _setargv and
> setargv.obj but I've never used it. It's quite possible this module is
> linked to the gcc projects compiled under Windows to emulate the Unix
> style shell wildcard expansion observed by the OP.
>

It goes back to even the old DOS days.
I found that setargv.obj file also with
Microsoft (R) C Optimizing Compiler Version 6.00A
And I sort of remember using it once.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      01-14-2013
On 01/14/2013 01:26 AM, Robert Wessel wrote:
> On Sun, 13 Jan 2013 23:53:54 -0500, James Kuyper
> <(E-Mail Removed)> wrote:
>
>> On 01/13/2013 08:34 PM, Alan Curry wrote:

....
>>> In the editor "vim", the command for "move to beginning of file" is gg.
>>> No shifting necessary! The classic vi command is 1G (i.e. Goto line 1),
>>> which does involve a shift key to generate the G, but the editor doesn't
>>> *know* that you used the shift key. Typing "1g" with caps-lock on would
>>> do the same thing. The editor can't tell the difference. It only knows
>>> that it received an uppercase G (ASCII code 71).
>>>
>>> Have you ever used a unix text editor before deciding you needed to make
>>> a new one?

>>
>> Bart appears to be a follower of the NIH (Not Invented Here) principle.
>> He wants to reinvent everything himself; nothing designed by anyone else
>> is good enough to be used without modification.

>
>
> You're complaining about Bart's motivations after someone brought up
> vi as an example of how to do something?!


Well, yes, but there's no direct connection between those events. I also
went to sleep "after someone brought up vi as an example of how to do
something" - but that doesn't mean Alan's message put me to sleep.

What you're describing happened only in the first paragraph of Alan's
that I quoted. It's the second one that actually triggered my response,
not the first. That's why I quoted the second one, and why I placed my
response immediately after it. I quoted the first paragraph only to put
the second one in it's appropriate context.

Also, my comments were triggered not just by this particular thread, but
also by many other threads in which Bart has decided to go off on his
own and create new tools, because of his dissatisfaction with some of
the features of tools designed by other people, features he considers
bugs. I don't object to him spending his time reinventing things; it's
his time to spend as he wants. Spending it that way means he has less
time to spend inventing completely new things, and it also means that
when he does invent new things, they often depend upon his reinvented
tools, in ways that would inhibit their adoption by other people - but
it's his decision to make about how important those issues are.

It just gets a bit annoying when he complains so much about the fact
that things other people designed work differently from the way he
expected them to. A bit more experience with such systems, if collected
with an open mind, could greatly improve his own design repertoire.
--
James Kuyper
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      01-14-2013
"Alan Curry" <(E-Mail Removed)> wrote in message
news:kcvnav$5m5$(E-Mail Removed)...
> In article <V6GIs.2274$(E-Mail Removed)7>, BartC <(E-Mail Removed)> wrote:


>>o Being able to write text at (row, column) on a screen or console window,
>>preferably in a choice of primary colours. (Both sets of curses seem just
>>about capable of that)


> In the editor "vim", the command for "move to beginning of file" is gg.
> No shifting necessary! The classic vi command is 1G (i.e. Goto line 1),
> which does involve a shift key to generate the G, but the editor doesn't
> *know* that you used the shift key. Typing "1g" with caps-lock on would
> do the same thing. The editor can't tell the difference. It only knows
> that it received an uppercase G (ASCII code 71).


(So how do you insert 1G or 1g into the file itself?)

> Have you ever used a unix text editor before deciding you needed to make
> a new one?


Yes, I've played with them. They reminded me of those line-editors I used to
use on teletypes.

> The ASCII + ECMA-48 terminal paradigm has its
> disadvantages but it's available everywhere, good enough most of the
> time, the old users are used to it, and the new users faint instantly at
> the sight of text mode so they won't appreciate any improvements to it.


I've looked up ECMA-48, and I think now I can dispense with Curses (for
linux; while on Windows I use what I had before).

I can directly send escape codes to stdout to give me cursor positioning,
and bold (I haven't tested colour yet, but that is not critical).

And, with the help of downloaded versions of kbhit() and getch() which
modify how getchar() works, I can directly get keyboard entry, even if some
keys are escape sequences. There are still missing modifiers, but I can live
with that too. (kbhit() is essential when writing an editor, to flush out
any pending keystrokes, which otherwise cause problems when the screen can't
keep up).

Now what I want to know is, what on earth is curses, ncurses or PDcurses
actually for?!

Anyway, thanks.

--
Bartc

 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      01-14-2013


"James Kuyper" <(E-Mail Removed)> wrote in message
news:kd0313$atm$(E-Mail Removed)...
> On 01/13/2013 08:34 PM, Alan Curry wrote:


>> Have you ever used a unix text editor before deciding you needed to make
>> a new one?

>
> Bart appears to be a follower of the NIH (Not Invented Here) principle.
> He wants to reinvent everything himself; nothing designed by anyone else
> is good enough to be used without modification.


(It's habit. I used to design and build my own hardware too (in the form of
microprocessor and graphics boards). Since these didn't come with software,
that had to be created as well, from scratch (literally, at one time,
starting from binary machine code). That included languages, editors,
libraries, compilers, and as well as everything associated with graphic
displays.

I don't do hardware any more, but it gives me a different perspective on
things, such as being able to tell when things are far bigger and more
complex than necessary.)

--
Bartc

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      01-14-2013
On 01/14/2013 08:36 AM, BartC wrote:
> "Alan Curry" <(E-Mail Removed)> wrote in message
> news:kcvnav$5m5$(E-Mail Removed)...

....
>> In the editor "vim", the command for "move to beginning of file" is gg.
>> No shifting necessary! The classic vi command is 1G (i.e. Goto line 1),
>> which does involve a shift key to generate the G, but the editor doesn't
>> *know* that you used the shift key. Typing "1g" with caps-lock on would
>> do the same thing. The editor can't tell the difference. It only knows
>> that it received an uppercase G (ASCII code 71).

>
> (So how do you insert 1G or 1g into the file itself?)


By first switching from command mode to edit mode. Several commands put
vi into edit mode, including 'i' == insert, 'a' = append, and 'o' = open
new line. You escape from edit mode back to command mode by hitting the
escape key. More modern editors typically use a menu to do the same
things that vi does through commands, and therefore don't need separate
command and edit modes.
I would never recommend vi for new users, the learning curve is too
steep. However, having already ascended that curve, I find vi easier to
use than those more modern editors.

>> Have you ever used a unix text editor before deciding you needed to make
>> a new one?

>
> Yes, I've played with them. They reminded me of those line-editors I used to
> use on teletypes.


That's not surprising, vi is much more than a line editor, but it was
developed from an older line editor named ex, and still supports the
entire ex command set.
--
James Kuyper
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-14-2013
"BartC" <(E-Mail Removed)> writes:
<snip>
> I've looked up ECMA-48, and I think now I can dispense with Curses
> (for linux; while on Windows I use what I had before).
>
> I can directly send escape codes to stdout to give me cursor
> positioning, and bold (I haven't tested colour yet, but that is not
> critical).
>
> And, with the help of downloaded versions of kbhit() and getch() which
> modify how getchar() works, I can directly get keyboard entry, even if
> some keys are escape sequences.


What does "directly get" mean? The right way to get keyboard input is
by reading the characters that come from the terminal emulator (or the
real terminal in the unlikely event you have one connected) via the tty
device or a pseudo tty device. You've previously talked about direct
access to the keyboard in a way that suggests you don't like this model,
but any code that tries to bypass all this is unlikely to play well with
other programs.

Can you link to the kbhit and getch code? Most of the ones that come
up in a search don't do much at all. curses allows you to do
non-blocking reads and, after calling the keypad function, the curses
input functions do pretty much what getch does.

> There are still missing modifiers, but
> I can live with that too. (kbhit() is essential when writing an
> editor, to flush out any pending keystrokes, which otherwise cause
> problems when the screen can't keep up).


Do you really want an editor that drops keystrokes?

> Now what I want to know is, what on earth is curses, ncurses or
> PDcurses actually for?!


To do what you've decided to do but in a more portable way. I suggested
extending the input function so that it can return more keycodes
(provided you accept that not all terminals can generate them all) but a
quick test reveals that it already does this. I.e. in an xterm which
can generate all these combinations, wgetch will return distinct codes
for Home, Shift+Home, Ctrl+Home, Alt+Home, Ctrl+Alt+Home and so on for
others that I did not test.

--
Ben.
 
Reply With Quote
 
Alan Curry
Guest
Posts: n/a
 
      01-14-2013
In article <lUTIs.1$(E-Mail Removed)7>, BartC <(E-Mail Removed)> wrote:
>"Alan Curry" <(E-Mail Removed)> wrote in message
>news:kcvnav$5m5$(E-Mail Removed)...
>
>I've looked up ECMA-48, and I think now I can dispense with Curses (for
>linux; while on Windows I use what I had before).

[...]
>
>Now what I want to know is, what on earth is curses, ncurses or PDcurses
>actually for?!


curses is for having a higher-level programming interface: It remembers where
the cursor is so you don't have to. It provides "windows" which you can
output to independently. It remembers what is currently on the screen and
buffers your writes, then when you flush the buffer to the screen it only
redraws the parts that have actually changed, minimizing the use of bandwidth
between the terminal and the host.

And it's also for supporting all the weird terminals that don't use ECMA-48
escape sequences. (man 5 terminfo, and look under "Glitches and Braindamage"
to get an idea of some of the terminal bugs that curses will work around
automatically.)

If you haven't done this yet, run the "infocmp" command on your Linux
console. It shows the terminal description used by ncurses to translate
high-level commands into escape sequences, and translate incoming escape
sequences into keycodes like KEY_LEFT. Then run "infocmp wyse50" and see how
different everything is.

Use curses instead of hardcoded ECMA-48 and your program may be usable on a
wider variety of ancient hardware.

ncurses is for having a curses clone that can be used without an expensive
AT&T UNIX(r) license.

pdcurses is for porting unix curses programs to DOS, I guess, but obviously
it grew a lot more features after that goal was satisfied.

--
Alan Curry
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      01-14-2013
Sjouke Burry <s@b> wrote:

(snip, someone wrote)

>> In that case I believe you might be referring to _setargv and
>> setargv.obj but I've never used it. It's quite possible this module is
>> linked to the gcc projects compiled under Windows to emulate the Unix
>> style shell wildcard expansion observed by the OP.


> It goes back to even the old DOS days.
> I found that setargv.obj file also with
> Microsoft (R) C Optimizing Compiler Version 6.00A
> And I sort of remember using it once.


Yes, that is the one. Well, it also ran on OS/2, which is where
I used it most.

I even had GNU diff and grep compiled with it and running on
OS/2 1.0, where, to be unix-like, it needed _setargv.

(And when unix systems were too expensive for home use.)

Which reminds me of the problem I had porting diff and grep.

They often used 0 as an argument that should have been (void*)0,
hopefully the expansion of NULL. (and before function prototypes,
maybe just barely before.)

When I complained to the GNU group, the reply was something like
that anyone running on a system with a different sized int
and (void*) deserved what they got.

Seemed pretty mean to me at the time.

-- glen

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Run Unix shell command $ parse command line arguments in python rkoida@yahoo.com Python 4 04-23-2005 04:42 AM
Documentation on command line arguments to perl Peter Kay Perl 1 05-18-2004 01:27 AM
command line arguments Ashe Corven C++ 3 05-08-2004 06:56 PM
How to hide command line arguments in a windows application SC C++ 2 05-05-2004 10:06 AM
Parser for command line arguments? Ahmed Moustafa Java 0 08-21-2003 05:21 AM



Advertisments