«

"BartC" <> writes:
> "Alan Curry" <> wrote in message
> news:kcsn1h$ans$...
[...]
>> 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..)

None of these facilities are provided by standard C. I suggest
comp.unix.programmer would be a better place for your questions.

Some friendly advice: Telling them that Unix has been doing things
wrong is not likely to be constructive.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

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

In article <J8oIs.8135$7>, BartC <> wrote:
>
>
>"Alan Curry" <> wrote in message
>>
>> 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 assume as a newcomer to the platform you're trying to write programs the
simplest way possible. That means using stdio, and that means you're
accessing an ASCII-based character stream. Not raw key events.

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

So far so good.

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

I can never quite understand what DOS and Windows programmers mean when they
use the word "console". In unix, the console is just a regular terminal,
which happens to be the destination for kernel messages. And it can be any
kind of terminal - it might be attached to a serial port or it might be a
remote node on the network.

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

"Everything as a serial stream of ASCII codes" is a good candidate for short
statement of the unix philosophy...

Really, it's just backward compatibility. The unix culture started with
hardware terminals that sent ASCII over a serial line to a host computer, and
tons of programs were developed to use that interface.

Later when keyboards and monitors directly connected to the unix host became
common, we didn't want to throw all of our existing code away, so we retained
the old "ASCII terminal" paradigm by including an emulator in the kernel.
That's why the default Linux console is a VT100 emulator running on top of
the PC keyboard and video hardware, with your stdin and stdout connected to
the emulated serial line.

Of course there were people with dreams of fancier user interfaces, and they
built the X Window System. And on top of that they built KDE and GNOME and
other fancy stuff.

Those are the two major user interface possibilities for unix programs:
ASCII/UTF-8 stdin/stdout, or GUI on top of X11. There isn't a "middle of the
road" interface that looks like a plain text terminal but provides detailed
information about key events. Not one that's widely used at least.

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

Did you know there are approximately 17 zillion text editors already? Can you
really hate *all* of them enough to justify adding another?

The minimum set of keys that are certain to be available on all terminals is
the printable ASCII set. Actually, probably less than that. Somebody out
there might still have a functioning uppercase-only terminal.

--
Alan Curry

On Jan 11, 3:58*am, "BartC" <b...@freeuk.com> wrote:
> I've just discovered that a single command line argument containing
> wildcards, such as *.c, is expanded to a full list of matching files before
> it gets to main().

Am I the only one annoyed that in Linux
cp none*
produces
cp: No match
?? It implies, falsely that the message comes from 'cp'.
It may seem nitpicky, but such misleading does NOT aid understanding.

(My comment is off-topic, but so is the whole thread.)

James

"Robert Wessel" <> wrote in message
news:...
> On Sun, 13 Jan 2013 08:46:37 +0000 (UTC), (Alan
> Curry) wrote:

>>Those are the two major user interface possibilities for unix programs:
>>ASCII/UTF-8 stdin/stdout, or GUI on top of X11. There isn't a "middle of
>>the
>>road" interface that looks like a plain text terminal but provides
>>detailed
>>information about key events. Not one that's widely used at least.
>
>
> But there is for Windows. He's used those facilities, and he'd like
> to port his application to *nix.

Yes, exactly. I'd even gone as far as going through PDcurses under Windows
(a version of ncurses), so that it'd would work painlessly under Linux - as
I thought.

> Maybe his application does something
> logical when you tap the alt key three times while holding
> ctrl-shift-backspace and wiggling the mouse. I'd probably be a poor
> customer for that application, since I don't think I'm coordinated
> enough to use that UI.

I want to use Ctrl+Home, for example, to get to the top of a document.

PDcurses returns that under Windows (but not Shift+Ctrl+Home, which marks
text from here to the top of the file).

But Ncurses under Linux doesn't recognise *any* shift combinations for keys
like Home!

So a Linux library ported to Windows, works better than it did under Linux!

>>Did you know there are approximately 17 zillion text editors already? Can
>>you
>>really hate *all* of them enough to justify adding another?

(And there are also zillions of cars on the roads; why not just take a taxi
instead of buying your own?!)

--
Bartc

Robert Wessel <> wrote:

(snip)

>>You'd have to decide what constitutes the raw command. 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! If you mean the command just before
>>file globing is done, then I'd ask again what makes globing the special
>>case?

> Not unreasonable questions. I'd say that anything past whatever
> specified the program to be executed and the end of the command being
> passed to that program, after doing any user specified processing,
> would be the "raw" input. Thus you'd not pass the stuff on the other
> side of a pipe, for example, or the text from before a command
> substitution ($()) was executed.

> Now I might quibble out the syntax of some of those, but that's a
> relatively minor complaint*. It's not that I object to globbing, it's
> that I think it's something I'd like to ask for, and ask for in
> specific places (IOW, I'd be happy to say "cl $(*.c)" if I wanted to
> compile all C program in the directory). IMO, the automatic globbing
> is genuinely useful in a small number of places, in many places being
> able to specify several inputs via a wild hard is occasionally handy
> but would be a complete non-issue to require explicit specification
> (because the single file name case is far more common), and a real
> PITA in others (let's just consider ls), to the point of making some
> things flat out impossible. The mistake is that catering for the
> small number of cases has messed up other stuff, when the small number
> of cases could have been better handled by providing those
> applications a globthisstring() function.

It works well with most unix commands, partly because they were
designed to work with it.

The unix ls command, for example, gives the files inside the specified
directory, unless -d is specified.

There are a few places where it is less convenient than it could
otherwise be, especially for those previously using other systems.

There is no standard unix command to do the equivalent of the
VMS or MS-DOS RENAME command with wild cards. Consider:

RENAME abc.* def.*

and compare to the result of typing

mv abc.* def.*

in unix.

Another case that fails is the unix dd commmand.

dd if=*.c of=xyz

will fail even if there is only one *.c file in the directory.

> Fundamentally, the shell has no idea what in a command might be a
> filename, and taking the approach that anything that looks like it
> might be a wild-carded filename should be treated as such is, IMO,
> rather silly. Something that was hacked in without enough
> consideration back in the dark ages sometime, and something were now
> stuck with. And has been pointed out in this thread, the way shells
> handle edge conditions (like a wildcard specification not matching any
> files) varies between shells.

-- glen

On 1/13/2013 04:22, James Dow Allen wrote:
> On Jan 11, 3:58 am, "BartC" <b...@freeuk.com> wrote:
>> I've just discovered that a single command line argument containing
>> wildcards, such as *.c, is expanded to a full list of matching files before
>> it gets to main().
>
> Am I the only one annoyed that in Linux
> cp none*
> produces
> cp: No match
> ?? It implies, falsely that the message comes from 'cp'.
> It may seem nitpicky, but such misleading does NOT aid understanding.
>
> (My comment is off-topic, but so is the whole thread.)
>

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

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter

Now, far afield from C, we come to

On Sunday 13 January 2013 07:10, in comp.lang.c, wrote:
[snip]
> I want to use Ctrl+Home, for example, to get to the top of a document.
>
> PDcurses returns that under Windows (but not Shift+Ctrl+Home, which marks
> text from here to the top of the file).
>
> But Ncurses under Linux doesn't recognise *any* shift combinations for
> keys like Home!

Often, an X "GUI desktop" will reserve some shift combinations for itself.
In KDE 3.5, for instance, <shift><home> is reserved for KDE's "home"
function.

Be mindful of the environment. Curses can only receive keysequences that the
OS (or it's proxys, like X and it's window managers) pass to it. Try
running your curses-based program in a raw terminal, not under X control.


> So a Linux library ported to Windows, works better than it did under
> Linux!

Not really. Windows does less than Linux does. And PDCurses is /not/ curses;
it is a Curses subset, written for Microsoft DOS applications. Hence, it
works within the confines (limits and abilities) of a DOS environment,
and /not/ within the limits and abilities of a Unixish environment.

FWIW, Curses (on Linux) supports the KEY_SHOME (shifted home) key.


[snip]
--
Lew Pitcher
"In Skills, We Trust"

Lew Pitcheræ–¼ 2013å¹´1月14日星期一UTC+8上å�ˆ12時21分44ç§ ’寫é�“：
> Now, far afield from C, we come to
>
>
>
> On Sunday 13 January 2013 07:10, in comp.lang.c, wrote:
>
> [snip]
>
> > I want to use Ctrl+Home, for example, to get to the top of a document.
>
> >
>
> > PDcurses returns that under Windows (but not Shift+Ctrl+Home, which marks
>
> > text from here to the top of the file).
>
> >
>
> > But Ncurses under Linux doesn't recognise *any* shift combinations for
>
> > keys like Home!
>
>
>
> Often, an X "GUI desktop" will reserve some shift combinations for itself..
>
> In KDE 3.5, for instance, <shift><home> is reserved for KDE's "home"
>
> function.
>
>
>
> Be mindful of the environment. Curses can only receive keysequences that the
>
> OS (or it's proxys, like X and it's window managers) pass to it. Try
>
> running your curses-based program in a raw terminal, not under X control.
>
>
>
>
>
> > So a Linux library ported to Windows, works better than it did under
>
> > Linux!
>
>
>
> Not really. Windows does less than Linux does. And PDCurses is /not/ curses;
>
> it is a Curses subset, written for Microsoft DOS applications. Hence, it
>
> works within the confines (limits and abilities) of a DOS environment,
>
> and /not/ within the limits and abilities of a Unixish environment.
>
>
>
> FWIW, Curses (on Linux) supports the KEY_SHOME (shifted home) key.
>
>
>
>
>
> [snip]
>
> --
>
> Lew Pitcher
>
> "In Skills, We Trust"

Acctually DOS 3.X to DOS4.X only supported
non-re-entrant IRT and a simple command invoker
that worked in the real memory under 640K but
could be shelled in a primitive way still within
the memory limit.

Anyway, I got my 1024X768X256 color multi-sync
color monitor from Matsushita's Panasoic logo
and VGA card to experiment on the DOS part in
1991-1992 for a budget about USD 1000 at that time.

Anyway I was managed to do quite a few
interesting things at that time without resorting
to an infant linux system to show 256 color images.

Willem <> writes:

> BartC wrote:
> ) I've just discovered that a single command line argument containing
> ) wildcards, such as *.c, is expanded to a full list of matching files before
> ) it gets to main().
>
> It gets expanded even before the program is started, by the shell.
>
> ) That isn't really what I want (and there could be thousands of matching
> ) files, which I may not want to deal with in my C program, but pass on to
> ) something else, or the argument may not be a file specification at all).
> )
> ) Is there any way this behaviour can be changed, without needing to write
> ) arguments in a special way?
>
> No.

Almost certainly yes, but it depends on the shell being used, as it's a feature of the shell.

E.g. in bash:

$ ls *.ppm
IMG_8013.ppm IMG_8014.ppm IMG_8015.ppm IMG_8016.ppm IMG_8017.ppm IMG_8018.ppm IMG_8021.ppm middle.ppm

$ set -f

$ ls *.ppm
ls: cannot access *.ppm: No such file or directory

Phil
--
I'm not saying that google groups censors my posts, but there's a strong link
between me saying "google groups sucks" in articles, and them disappearing.

Oh - I guess I might be saying that google groups censors my posts.