1. command_line() help
-------Phoenix-Boundary-07081998-
Is it possible to get the actual line that invoked my Euphoria program=3F
command_line() slices up the line in ways that are hard or impossible
to deal with. For example:
c:> exw test desc =3D"A test"
or
c:> exw test desc =3D "A \"BAD\" test"
or
c:> exw test dest =3D "\"Copy of foo\".e"
I realize these are rather esoteric cases, but command lines with
assorted flags and strings get quite difficult to handle, and it is even
harder to document just what command lines will accept.
Having access to the command line as entered would allow me to be
as sophisticated as I desired in parsing it. Better yet would be if
command_line() itself could handle strings well.
Does the OS hide the actual invocation line=3F=3F
Do the compilers hide it=3F=3F
Karl Bochert
-------Phoenix-Boundary-07081998---
2. Re: command_line() help
- Posted by irvm at ellijay.com
Jul 15, 2001
On Sunday 15 July 2001 16:55, kbochert at ix.netcom.com wrote:
> Is it possible to get the actual line that invoked my Euphoria program?
>
> command_line() slices up the line in ways that are hard or impossible
> to deal with. For example:
> c:> exw test desc ="A test"
> or
> c:> exw test desc = "A \"BAD\" test"
> or
> c:> exw test dest = "\"Copy of foo\".e"
This is only difficult to deal with if you insist on "escaping" the quotes.
If you just enter this as
exw test dest = "Copy of foo.e"
then the command line returns:
exu
test
dest
=
Copy of foo.e
Wouldn't seem too difficult to reconstruct the command line if
you really want the hassle of breaking it back down again:
sequence cmd ,c
cmd = command_line()
c = {}
for i = 1 to length(cmd) do
printf(1,"%s\n",{cmd[i]})
c &= " " & cmd[i]
end for
c now contains exu test dest = Copy of foo.e
Regards,
Irv
3. Re: command_line() help
Karl Bochert writes:
> Is it possible to get the actual line that invoked my Euphoria program?
There's a C routine in the WIN32 API:
LPTSTR GetCommandLine(VOID)
It returns a pointer to a 0-terminated command-line string.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: command_line() help
- Posted by euman at bellsouth.net
Jul 16, 2001
I was under the assumption that lpzstr
was a 0-terminated string.
would someone explain what the "lpt" is?
and why is there a difference in the name?
Euman
euman at bellsouth.net
> There's a C routine in the WIN32 API:
>
> LPTSTR GetCommandLine(VOID)
>
> It returns a pointer to a 0-terminated command-line string.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
5. Re: command_line() help
- Posted by euman at bellsouth.net
Jul 16, 2001
OK, LPT stands for the Device or console
and the STR is the sting representation for
the device or console.
I just didnt think about it real hard.
Euman
euman at bellsouth.net
> I was under the assumption that lpzstr
> was a 0-terminated string.
>
> would someone explain what the "lpt" is?
>
> and why is there a difference in the name?
>
> Euman
> euman at bellsouth.net
>
> > There's a C routine in the WIN32 API:
> >
> > LPTSTR GetCommandLine(VOID)
> >
> > It returns a pointer to a 0-terminated command-line string.
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > http://www.RapidEuphoria.com
>
>
>
>
>
>
>
6. Re: command_line() help
----- Original Message -----
From: <euman at bellsouth.net>
To: "EUforum" <EUforum at topica.com>
Subject: Re: command_line() help
>
> I was under the assumption that lpzstr
> was a 0-terminated string.
An LPZSTR is a Long Pointer to a Zero-terminated String.
That is, it contains a 32-bit address of the first byte in a #00 terminated
array of bytes.
> would someone explain what the "lpt" is?
An LPTSTR is a Long Pointer to a Zero-terminated wide-character String.
That is, it contains a 32-bit address of the first unsigned 16-bit number in
a #0000 terminated array of unsigned 16-bit numbers.
The definition here comes from the Windows SDK.
typedef unsigned short WCHAR; // wc, 16-bit UNICODE character
typedef WCHAR *LPWSTR;
typedef LPWSTR LPTSTR;
> and why is there a difference in the name?
LPZSTR points to a set of bytes, and LPTSTR points to a set of 16-bit
numbers.
LPTSTR is used for unicode characters. When using the UTF-8 encoding scheme,
the ASCII character set maps into the unicode characters set with the same
bit patterns. Thus, you can use LPTSTR or LPZSTR if you are only dealing
with ASCII characters, but you must use LPTSTR is you also have other
unicode characters in the same string.
If you read further into the SDK documentation on GetCommandLine() there is
this statement:
"The reason that main() and WinMain() cannot return Unicode strings is that
argc, argv, and lpCmdLine use the LPSTR data type for parameters, not the
LPTSTR data type. The GetCommandLine function can be used to access Unicode
strings, because it uses the LPTSTR data type. "
-----
cheers,
Derek
7. Re: command_line() help
- Posted by euman at bellsouth.net
Jul 16, 2001
I also thought that unicode was for non-american
text. I realise there is more to this than just that.
Would you care to explain?
Euman
euman at bellsouth.net
----- Original Message -----
From: "Derek Parnell" <ddparnell at bigpond.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: command_line() help
>
>
> ----- Original Message -----
> From: <euman at bellsouth.net>
> To: "EUforum" <EUforum at topica.com>
> Sent: Tuesday, July 17, 2001 4:37 AM
> Subject: Re: command_line() help
>
>
> >
> > I was under the assumption that lpzstr
> > was a 0-terminated string.
>
> An LPZSTR is a Long Pointer to a Zero-terminated String.
> That is, it contains a 32-bit address of the first byte in a #00 terminated
> array of bytes.
>
> > would someone explain what the "lpt" is?
>
>
> An LPTSTR is a Long Pointer to a Zero-terminated wide-character String.
> That is, it contains a 32-bit address of the first unsigned 16-bit number in
> a #0000 terminated array of unsigned 16-bit numbers.
>
> The definition here comes from the Windows SDK.
>
> typedef unsigned short WCHAR; // wc, 16-bit UNICODE character
> typedef WCHAR *LPWSTR;
> typedef LPWSTR LPTSTR;
>
> > and why is there a difference in the name?
>
> LPZSTR points to a set of bytes, and LPTSTR points to a set of 16-bit
> numbers.
>
> LPTSTR is used for unicode characters. When using the UTF-8 encoding scheme,
> the ASCII character set maps into the unicode characters set with the same
> bit patterns. Thus, you can use LPTSTR or LPZSTR if you are only dealing
> with ASCII characters, but you must use LPTSTR is you also have other
> unicode characters in the same string.
>
> If you read further into the SDK documentation on GetCommandLine() there is
> this statement:
>
> "The reason that main() and WinMain() cannot return Unicode strings is that
> argc, argv, and lpCmdLine use the LPSTR data type for parameters, not the
> LPTSTR data type. The GetCommandLine function can be used to access Unicode
> strings, because it uses the LPTSTR data type. "
>
> -----
> cheers,
> Derek
>
>
>
>
8. Re: command_line() help
On 16 Jul 2001, at 19:00, euman at bellsouth.net wrote:
>
> I also thought that unicode was for non-american
> text. I realise there is more to this than just that.
> Would you care to explain?
The Chinese and some others were told to forget using thousands of chars
because 16bits wouldn't hold them. Then came 32bit unicode, and because
of the way it was implemented, it won't hold them all either. Rather rude of
the US designers to tell people they can't spell their names on the puter
properly, in my opinion.
Kat
> Euman
> euman at bellsouth.net
>
>
> ----- Original Message -----
> From: "Derek Parnell" <ddparnell at bigpond.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Monday, July 16, 2001 16:04
> Subject: Re: command_line() help
>
>
> >
> >
> > ----- Original Message -----
> > From: <euman at bellsouth.net>
> > To: "EUforum" <EUforum at topica.com>
> > Sent: Tuesday, July 17, 2001 4:37 AM
> > Subject: Re: command_line() help
> >
> >
> > >
> > > I was under the assumption that lpzstr
> > > was a 0-terminated string.
> >
> > An LPZSTR is a Long Pointer to a Zero-terminated String.
> > That is, it contains a 32-bit address of the first byte in a #00 terminated
> > array of bytes.
> >
> > > would someone explain what the "lpt" is?
> >
> >
> > An LPTSTR is a Long Pointer to a Zero-terminated wide-character String.
> > That is, it contains a 32-bit address of the first unsigned 16-bit number in
> > a
> > #0000 terminated array of unsigned 16-bit numbers.
> >
> > The definition here comes from the Windows SDK.
> >
> > typedef unsigned short WCHAR; // wc, 16-bit UNICODE character
> > typedef WCHAR *LPWSTR;
> > typedef LPWSTR LPTSTR;
> >
> > > and why is there a difference in the name?
> >
> > LPZSTR points to a set of bytes, and LPTSTR points to a set of 16-bit
> > numbers.
> >
> > LPTSTR is used for unicode characters. When using the UTF-8 encoding scheme,
> > the ASCII character set maps into the unicode characters set with the same
> > bit
> > patterns. Thus, you can use LPTSTR or LPZSTR if you are only dealing with
> > ASCII characters, but you must use LPTSTR is you also have other unicode
> > characters in the same string.
> >
> > If you read further into the SDK documentation on GetCommandLine() there is
> > this statement:
> >
> > "The reason that main() and WinMain() cannot return Unicode strings is that
> > argc, argv, and lpCmdLine use the LPSTR data type for parameters, not the
> > LPTSTR data type. The GetCommandLine function can be used to access Unicode
> > strings, because it uses the LPTSTR data type. "
> >
> > -----
> > cheers,
> > Derek
> >
> >
> >
> >
>
>
>
>
>
>
9. Re: command_line() help
> From: Kat <gertie at PELL.NET>
> To: EUforum <EUforum at topica.com>
> Reply-To: EUforum at topica.com
> Subject: Re: command_line() help
> Date: 17/07/2001 3:48:01 PM
>
> >
> > I also thought that unicode was for non-american
> > text. I realise there is more to this than just that.
> > Would you care to explain?
>
> The Chinese and some others were told to forget using
> thousands of chars
> because 16bits wouldn't hold them. Then came 32bit unicode,
> and because
> of the way it was implemented, it won't hold them all either.
> Rather rude of
> the US designers to tell people they can't spell their names
> on the puter
> properly, in my opinion.
Hi Kat,
I didn't know this.
>From my reading I understood that all the 4 billion-odd Unicode characters
could be implemented. I know that certain subsets of the the various Chinese
character sets have been standardized, and I don't think that there are any
commonly used Chinese characters that are not defined. There may be some
archaric forms that have not yet been codified, but there doesn't seem to be
anything stopping that process except time.
I'm amused to see some ancient scripts have been planned for (Linear-B,
Cuniform, Minoan, Mayan, Phoenecian, Hieroglyphic).
----
Derek
confidential information intended solely for the use of the individual or
entity to whom they are addressed. If you are not the intended recipient of
this message you are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you have
received this message in error please notify the sender immediately. Any
views expressed in this message are those of the individual sender and may
not necessarily reflect the views of Global Technology Australasia Limited.
10. Re: command_line() help
On 17 Jul 2001, at 16:25, Derek Parnell wrote:
> >
> > The Chinese and some others were told to forget using
> > thousands of chars
> > because 16bits wouldn't hold them. Then came 32bit unicode,
> > and because
> > of the way it was implemented, it won't hold them all either.
> > Rather rude of
> > the US designers to tell people they can't spell their names
> > on the puter
> > properly, in my opinion.
>
> Hi Kat,
> I didn't know this.
> >From my reading I understood that all the 4 billion-odd Unicode characters
> could be implemented.
The 32 bits isn't "flat", it's "segmented" like cpu address space in dos mode.
I don't know the segment size, but from what i understand, each language
gets one segment whether it needs far more or far less.
> I know that certain subsets of the the various Chinese
> character sets have been standardized, and I don't think that there are any
> commonly used Chinese characters that are not defined. There may be some
> archaric forms that have not yet been codified, but there doesn't seem to be
> anything stopping that process except time.
Well, except for the lack of space in the 32bits as they are laid out now. In
terms of complexity, not even the 32bits of data is "flat", it's 2 16bit words,
manipulated separately and differently.
> I'm amused to see some ancient scripts have been planned for (Linear-B,
> Cuniform, Minoan, Mayan, Phoenecian, Hieroglyphic).
Maybe they have changed it.... i haven't been following closely.
Kat
