Command line arguments

[James Kuyper]

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.

 

[JohnF]

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.

 

[Sjouke Burry]

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.

 

[James Kuyper]

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.

 

[BartC]

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]

On 01/13/2013 08:34 PM, Alan Curry wrote:

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

 

[James Kuyper]

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

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.

 

[Ben Bacarisse]

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.

 

[Alan Curry]

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.

 

[glen herrmannsfeldt]

(snip, someone wrote)

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

 

[BartC]

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.

OK. But all things I don't really need. And I've never had to worry about
'refresh' before; why start now!

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

I quite like ECMA-48. In fact I'm trying out an emulator for Windows
console. (But I wouldn't recommend anyone reading the 108-page ISO document
as it's utterly incomprehensible. The Wikipedia page shows the main things
that you need to know.)

 

[BartC]

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.

I mean, without something having to press Enter to complete a line of text
before any keys are available. That would be a bit awkward with a program
like an editor, or if you wanted your own line-input routine. In Windows, I
used kbhit() and getch() for unsophisticated keyboard entry (doing it
properly via a Console API gets hairy, but it will work).

Can you link to the kbhit and getch code?

I tried this for getch():

http://cboard.cprogramming.com/faq-board/27714-faq-there-getch-conio-equivalent-linux-unix.html

And this for kbhit():

http://geezer.osdevbrasil.net/software/kbhit.c

(I remember solving this for an ASR33, I didn't think I'd be facing the same
problem 35 years later!)

Do you really want an editor that drops keystrokes?

Yes. For normal typing of text, it's unlikely the display will not keep up
with the rate of typing. But imagine that someone holds down the PageDown
key on a long document: the key repeats at 20cps, but the display might only
update at 10 screens per second. When the user releases the key, there might
be dozens of keystrokes pending, but the screen will keep on scrolling down
well past the desired position.

I've seen any amount of software having this sort of annoying problem (even
web browers, although associated then with mouse events and scroll bars).

(PDcurses has some logic that if a key is pressed during a 'refresh'
operation, then all pending screen updates are disabled. But I don't see
how that would work well. Likely nothing will be seen until... when? Usually
the user will keep the key pressed until he/she recognises the desired
page or at least the general location; the update is needed. But the feature
can be turned off...)

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.

I don't understand unix/linux well enough so the slightest problem eats up
huge amounts of time: something little doesn't work, then the thing needed
to fix it has its own problems, then you realise you're trying to solve
things which have no apparent connection with what you're trying to do. This
was the case with trying to get Curses working with the alternate Debian
distro I have.So I'd rather not have that dependency on Curses. And I didn't
like it's interface anyway.

(Actually I spent quite some time the other day trying to establish whether
Lxterminal, which I use, is the same thing as Xterm; I'm still not sure!)

BTW by wgetch() you mean the curses function? That's the one I'd been using.

 

[Shao Miller]

It does? When I do that, it says:

cp: missing destination file operand after `none*'

When I do 'cp none* .', it says:

cp: cannot stat `none*': No such file or directory

It's come up elsthread:

[jsowden@arcturus:~] $ tcsh -c 'cp none*'
cp: No match.
[jsowden@arcturus:~] $ bash -c 'cp none*'
cp: missing destination file operand after `none*'
Try `cp --help' for more information.

Aha. I appreciate you sharing that, as I haven't been following that
discussion.

I don't use 'tcsh', but I wonder if it documents under which
circumstances it will put a program name before a colon and yield a
message, if ever.

 

[glen herrmannsfeldt]

On 1/14/2013 10:26, Azazel wrote:
(snip)

It's come up elsthread:
[jsowden@arcturus:~] $ tcsh -c 'cp none*'
cp: No match.
[jsowden@arcturus:~] $ bash -c 'cp none*'
cp: missing destination file operand after `none*'
Try `cp --help' for more information.

Aha. I appreciate you sharing that, as I haven't been following that
discussion.

It seems that tcsh has the nonomatch variable that, when set,
gives the bach behavior.

I don't use 'tcsh', but I wonder if it documents under which
circumstances it will put a program name before a colon and yield a
message, if ever.

I don't see a list of messages.

It is interesting, as it looks like the message is from ls,
where it is actually from the shell.

-- glen

 

[88888 Dihedral]

在 2013å¹´1月14日星期一UTC+8下åˆ11æ—¶26分35秒，Azazel写é“：

On 1/13/2013 04:22, James Dow Allen wrote:

It does? When I do that, it says:

cp: missing destination file operand after `none*'

When I do 'cp none* .', it says:

cp: cannot stat `none*': No such file or directory

It's come up elsthread:



[jsowden@arcturus:~] $ tcsh -c 'cp none*'

cp: No match.

[jsowden@arcturus:~] $ bash -c 'cp none*'

cp: missing destination file operand after `none*'

Try `cp --help' for more information.

I used Vi before, and I never liked Vi.
I use notepad++ now in writing programs and I could
connect to unix systems in the remote spots by Telnet
now.

Of course I could use VNC, too.

 

[Nobody]

I tried this for getch():

http://cboard.cprogramming.com/faq-board/27714-faq-there-getch-conio-...

And this for kbhit():

http://geezer.osdevbrasil.net/software/kbhit.c

Both of those have the same flaws: they don't install handlers to restore
the terminal state in the event of SIGTSTP, SIGQUIT, etc (or re-enable it
after SIGCONT), nor clear the ISIG bit in c_lflag.

 

[BartC]

Both of those have the same flaws: they don't install handlers to restore
the terminal state in the event of SIGTSTP, SIGQUIT, etc (or re-enable it
after SIGCONT), nor clear the ISIG bit in c_lflag.

Well, fortunately I have no idea what any of that means! Provided it works
in the one or two programs I need as stop-gaps, then I don't care.

In any case, from what I can see of the code, especially this simpler
version of kbhit():

http://cboard.cprogramming.com/c-programming/63166-kbhit-linux.html

the code sets a new attribute, then restores it. Do you have a better way of
doing it, or are you saying it is *impossible*, under Unix, to test whether
a key has been pressed on a locally attached keyboard, in a way that keeps
everyone happy?

 

[Keith Thompson]

Well, fortunately I have no idea what any of that means!

[snip]

Hooray for ignorance!

 

[Nobody]

Well, fortunately I have no idea what any of that means! Provided it works
in the one or two programs I need as stop-gaps, then I don't care.

It works so long as you don't hit Ctrl-C, Ctrl-\ or Ctrl-Z. Assuming that
those keys have their usual meaning, Ctrl-C sends SIGINT (default
behaviour: terminate the process), Ctrl-\ sends SIGQUIT (default
behaviour: terminate the process), Ctrl-Z sends SIGTSTP (default
behaviour: suspend the process).

If those keys are pressed, you'll probably be back in the shell, but the
terminal will now be in (semi-)raw mode, which the shell may or
may not be expecting. Even if it accounts for it, it will probably put the
terminal back into canonical mode if you resume a suspended process.

[At least bash will be expecting it, as it uses raw mode to implement
history, advanced editing, etc.]

In any case, from what I can see of the code, especially this simpler
version of kbhit():

http://cboard.cprogramming.com/c-programming/63166-kbhit-linux.html

the code sets a new attribute, then restores it. Do you have a better way of
doing it, or are you saying it is *impossible*, under Unix, to test whether
a key has been pressed on a locally attached keyboard, in a way that keeps
everyone happy?

The "better" way is to do that, but also install signal handlers for
signals which will suspend or terminate the process, and have those
handlers restore the terminal settings to their initial state. And also
install a signal handler for SIGCONT (which is received if the process is
resumed after having been suspended) to put the terminal into the state it
was in at the point that it was suspended.

Unlike stream buffering (setbuf etc), which is internal to each process,
the terminal state set by tcsettr() is associated with a terminal (i.e.
common to all processes using the terminal).

If you just (think you) want a "Press any key to continue" feature, you're
probably better off avoiding the issue altogether and just implementing a
"Press Return to continue" feature instead. That will work even if the
terminal itself (as opposed to the driver) is line-buffered.

If you need raw terminal input for other reasons, you should consider
whether you can use ncurses, which will deal with this stuff for you.

 

[Ben Bacarisse]

I mean, without something having to press Enter to complete a line of text
before any keys are available.

That's trivial. I thought you were complaining that ncurses does not
provide "direct access" to the keyboard. By this meaning of "direct
access" it does.

I tried this for getch():

http://cboard.cprogramming.com/faq-board/27714-faq-there-getch-conio-equivalent-linux-unix.html

And this for kbhit():

http://geezer.osdevbrasil.net/software/kbhit.c

Then I can't see why you don't use ncurses. They can do what these
functions do and they will do it better. They won't keep switching the
tty's input mode and they provide access to keyboard mappings that getch
won't. ncurses will also restore the terminal mode on exit (if used as
per the documentation) whereas getch as written above can leave the
terminal in an awkward state.

(I remember solving this for an ASR33, I didn't think I'd be facing the same
problem 35 years later!)

If you go about the way you are you'll have to solve it again and
again. ncurses solves it for a wide range of terminals and systems.

Yes. For normal typing of text, it's unlikely the display will not keep up
with the rate of typing. But imagine that someone holds down the PageDown
key on a long document: the key repeats at 20cps, but the display might only
update at 10 screens per second. When the user releases the key, there might
be dozens of keystrokes pending, but the screen will keep on scrolling down
well past the desired position.

I suspect that you are talking about your won private software, so it's
no matter to me, but I don't want either the problem you describe or
the solution you propose.

I don't understand unix/linux well enough so the slightest problem eats up
huge amounts of time: something little doesn't work, then the thing
needed to fix it has its own problems, then you realise you're trying
to solve things which have no apparent connection with what you're
trying to do. This was the case with trying to get Curses working with
the alternate Debian distro I have.So I'd rather not have that
dependency on Curses. And I didn't like it's interface anyway.

The fact that you encountered a problem does not mean that there was an
issue there at all. After all you "don't understand unix/linux well
enough" so there may simply have been a misunderstanding. I'd suggest
posting in comp.unix.programmer but they'll tell you to use ncurses and
I think you've decided not to, whatever the benefits.

(Actually I spent quite some time the other day trying to establish whether
Lxterminal, which I use, is the same thing as Xterm; I'm still not
sure!)

I would have thought the first line of manual page would have cleared
that up, but maybe you mean Xterm in some other sense.

BTW by wgetch() you mean the curses function? That's the one I'd been
using.

And if you use the keypad function, it will read and return key codes.
The ncurses way to do kbhit() is to turn off blocking reads (the nodelay
function) but it's not exactly the same because it works by trying to
get a character rather than telling of there is one to get. This is, in
*nix, the right way to do it. A function like kbhit can lie and lead to a
deadlock if the terminal driver flushes the input between the call to
kbhit and actually reading the character. It might be troublesome to
re-write code that uses the Windows model (where, presumably, kbhit
can't lie) so you might try winging it with a kbhit that just does the
select call.