Re: [ Attn: Randy ] Ad-hoc Parsing?

From: Phil Carmody (thefatphil_demunged_at_yahoo.co.uk)
Date: 12/30/04 

Date: 30 Dec 2004 02:49:59 +0200

Herbert Kleebauer <klee@unibwm.de> writes:
> Phil Carmody wrote:
> > Herbert Kleebauer <klee@unibwm.de> writes:
>
> > > The whole sub thread is about the statement, that batch scripting in
> > > DOS/Windows is at least as flexible as csh/sh/bash scripting in
> > > Unix/Linux.
>
> > Therefore
> > if people (T.M., Robert, myself) have been discussing the unix
> > shell without explicitly mentioning an OS, that means they have been making
> > statements _strictly_ about just the shell itself.
>
> Maybe you should switch from your write only mode to read mode.
> The discussion was about Linux compared to Windows:
>
> +---------------------------------------------------------------------
> | From: "T.M. Sommers" <tms@nj.net>
> | Subject: Re: [ Attn: Randy ] Ad-hoc Parsing?
> | Date: Thu, 16 Dec 2004 18:38:13 GMT
> |
> | > and this is exactely where Linux completely fails,
> | > and why almost no real final users want to use it.
> |
> | Linux has plenty of users; so does BSD.
> |
> | There are more people in the world than grannies and tots. If
> | you are aiming your OS at grannies and tots, then obviously it
> | must be usable by them, but if you are aiming your OS at people
> | who want to get real work done, then you have different
> | requirements. One of the biggest advantages of Unix-like shells
                                                      ^^^^^^^^^^^^^^^^
> | is that they allow the user to do things that the creator of the
> | shell never imagined.
> +---------------------------------------------------------------------
>
> The statement in the above posting is, that the command
> line interface in Unix is more powerful and flexible than
> the command line interface in Windows, because of the much
> better Unix-like shells (sh, csh, bash, ...) used in Unix/Linux
> compared to the command.com/cmd.exe shells in DOS/Windows.

Holy fucking *** - that hole in your foot's really got to hurt.

"Unix-like shells"

I'll repeat that -

"Unix-like shells"

If that isn't a hint that shells with the desired properties don't
only run under unix, I don't know what is.

> My answer was, that scripts in DOS/Windows (using the less
> powerful shells command.com or cmd.exe) are at least as
> flexible as the Unix scripts using the more powerful
> Unix-like shells, because they can extend their abilities
> by directly including CPU instructions (because of the
> header free .com file format).
>
> Your statement: "It (bash) can execute the .com file as
> easily as a command.com or cmd.exe batch file can", can
> in the above context only be interpreted as "It (bash
> in Unix) can ....".

That is simply wrong. It can only be interpreted as a comment
about bash, which being a fully-capable shell, can launch programs
of all types that either it (via #!) or the underlying OS can
execute. For some linux systems that's only ELF. For other linux
systems it's ELF, a.out and java. For cygwin systems, it's .BAT batch
scripts, .COM, MZ .EXE, and PE .EXE.

> This is simple wrong.

How self-referential!

> Then you changed
> your mind

Au contraire. I always had Cygwin on my mind. The only time I
ever see any of your or Annie's little .COM demos is from within
a cygwin window on my g/f's NT machine. I've never associated
sh specifically with unix - I was using sh on my Atari ST about 5
years before I ever touched a Unix system. Your pathetic pretence
that I initially only associated bash with unix, and then "changed
my mind" simply doesn't wash.

> and said, that you meant "It (bash in Windows) can ...".
> This simple doesn't make any sense in the above context.
>
> When I say, that, despite the less powerful Windows shells,
> Windows scripting is as flexible as Unix scripting because
> of the ability to include CPU instructions, then it doesn't
> make any sense to say, bash in Windows can also include
> CPU instructions and therefore bash scripts (in Windows)
> are at least as flexible as bash scripts (in UNIX).
 
Erm, I'm not sure I follow you. Bash, under any OS, can drop
arbitrary files, including executable ones. It's equally
flexible everywhere.
 
> > > The reason is, that there is a header free executable
> > > file format in DOS/Windows which makes it possible to directly
> > > embed cpu instructions within a DOS/Windows batch script.
> >
> > WRONG. For ***'s sake, Herbert, evolve. Your logic is just plain crap.
>
> > Therefore you cannot logically say that
> > the existence of .COM files "makes it possible to" do anything
> > of the sort.
>
> I never said this.

But the above is a direct quote.

> I said, it "makes it practicable".

You said "which makes it possible" - see above, after the
"in DOS/Windows" and before "to directly embed".

That's you speaking.

Are your drugs leading to multiple personality disorder as well now?

> I have
> a whole collection of such small com programs (which consist of
> a few echo lines only) which I include in batch files. But I would
> never have done this, if I had to include Win32 exe files. It
> also would be possible, but it is impractical.
 
If you chose PE, yes, they're bloated. Is MZ not supported anymore?

> > > The statement "It (bash) can execute the .com file as easily as
> > > a command.com or cmd.exe batch file can" without the addition
> > > "when bash is used in DOS/Windows" is not true. If it were true,
> > > than bash used with any operating system had to be able to execute
> > > .com files.
> >
> > Nope - it was a comparison of one scripting language to another
> > scripting language. I make no reference to the OS it is running
> > on; you ASSume that bash runs only under unix. I'm not going to
> > feel guilt that you are ignorant that bash runs under MS windows
> > too.
>
> Something with your logic must be wrong. Command.com and cmd.exe
> are bound to DOS/Windows, therefore a command/cmd script can
> always initiate the execution of .com program (it doesn't
> execute the com program itself). Bash is not bound to DOS/Windows,
> so bash can't always initiate the execution of .com program. Only
> when used in DOS/Windows, bash also can start a .com program.
> Therefore the statement "It (bash) can execute the .com file
> as easily as a command.com or cmd.exe batch file can" simple
> is wrong.

Can you find anywhere in the bash documentation where it specifies
the binary executable formats that it can launch? I don't think so,
because there's no such list. Bash can launch, via fork/exec system
calls, _precisely_ the binary formats that the underlying OS can
execute. On my ST, that includes TOS executables; on cygwin it
includes .EXEs; on linux it includes ELF files; on VAX it includes
VMS EXE files.

I repeat - bash can lauch any executable type that is recognised
as an executable type by the underlying OS. i.e. There is no
executable type that it can't launch, only types that the underlying
OS can't execute.

> > I repeatedly made statements about bash. You interpreted them
> > to only refer to bash on unix. Your mistake. Get over it.
>
> The same mistake. You didn't make statements about bash, but
> about bash in Windows.

WRONG. I made no mention of the underlying OS in my discussions of
bash's capabilities until the very final post where I dropped the
bombshell that you're still realing from - when I informed you
that cygwin's bash happily runs on windows.

> A statement about bash has to be true
> independent of the operating system.

But this is something where bash doesn't even care about the OS.
There's nothing intrinsically _about bash_ that prevents bash from
launching .COM files. Even on linux it will try to launch a .COM
file:

<<<
...
read(255, "#!/bin/sh\n./y_n.com\n", 20) = 20
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
brk(0) = 0x80eb000
brk(0x80ec000) = 0x80ec000
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
fork(Process 9717 attached
) = 9717
[pid 9717] --- SIGSTOP (Stopped (signal)) @ 0 (0) ---
[pid 9717] getpid() = 9717
[pid 9717] close(255) = 0
[pid 9717] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 9717] rt_sigaction(SIGTSTP, {SIG_DFL}, {SIG_DFL}, 8) = 0
[pid 9717] rt_sigaction(SIGTTIN, {SIG_DFL}, {SIG_DFL}, 8) = 0
[pid 9717] rt_sigaction(SIGTTOU, {SIG_DFL}, {SIG_DFL}, 8) = 0
[pid 9717] rt_sigaction(SIGINT, {SIG_DFL}, {SIG_DFL}, 8) = 0
[pid 9717] rt_sigaction(SIGQUIT, {SIG_DFL}, {SIG_IGN}, 8) = 0
[pid 9717] rt_sigaction(SIGCHLD, {SIG_DFL}, {0x8076f50, [], SA_RESTORER, 0x4008a5e8}, 8) = 0
[pid 9717] execve("./y_n.com", ["./y_n.com"], [/* 19 vars */]) = -1 ENOEXEC (Exec format error)
...
>>>

There - that execve - that's bash trying to launch the .COM file.
And that ENOEXEC - that's the OS saying no.

If you were to write a linux kernel extension that recognised .COM files
(which is pretty much impossible, or at least dangerous, as they have
no fingerprint), then the OS would not respond with that error, and
would instead do whatever your extension wanted to do (presumably
launch it within dosemu).
 
Bash is prepared to launch _anything_. Always was, always will be.
That is one of the things that helps make it OS-neutral, that fact
that it really doesn't give a *** about what it has no reason to
worry about. That's the OS's problem, and that's what ENOEXEC
return values are for.

> > > echo hP1X500P[PZBBBfh#b##fXf-V@`$fPf]f3/f1/5++u5>in.com
> > > is nothing but this CPU instructions:
> > > And this is possible because of the .com file format.
> >
> > Rearrange the following 5 letters to make a word - WRNOG.
> > If it's possible in unix to create ELF binaries using sh, then it (the
> > ability to drop small executables) _cannot_ be "because of the .com file
> > format".
>
> You really should start to read: "is NOTHING but this CPU instructions".
> Now show me your elf binary which "is NOTHING but this CPU instructions"

OK, you got me there. The .COM format is uniquely headerless amongst the
executable formats discussed. However, the reason you got me is because
that's an _utterly_ unimportant feature. I forgot that the lack of a header
was something that you have wet dreams about at night, and yet to the
rest of the world it's just not important at all. Why have you got hangups
about header structures?

What does it matter if an executable format has headers or not?
It's 45 bytes long, for pity's sake, why do you have a problem with that?

> > > > I can't live without features like independent stdout/stderr
> > > > redirecting and ${//} in bash, and the powerful single and double
> > > > quoting rules in all sensible unix shells, so I certainly can say
> > > > that I need the additional flexibility that bash gives me.
> > >
> > > Sorry, but that is "functionality" but not "flexibility". I never
> > > said, that bash isn't much more powerful than comannd.com/cmd.exe.
> > >
> > > In this sub thread "flexibility" was defined by:
> > >
> > > "T.M. Sommers" wrote:
> > >
> > > > One of the biggest advantages of Unix-like shells
> > > > is that they allow the user to do things that the creator of the
> > > > shell never imagined.
> >
> > That is a statement about shells.
>
> Yes, about the flexibility of a shell but you are speaking about the
> functionality of shell.
>
> >
> > > Now let's make a little test how flexible bash is. Let us do
> > > something which "the creator of the shell never imagined"
> > > (maybe the creator of the bashl had imagined this, so it is build
> > > into bash already, then we will have to find another example).
> >
> > OK, you're still talking about shells. Excellent, you've stayed
> > on topic for a whole paragraph.
>
> I'm always on topic. And on topic here means bash in Unix, not
> bash in Windows.

Wrong. It's a statement about bash, and you're all pissed off because
you were too naive to realise that bash runs under cygwin.
Go cry to your mummy, and then _get over it_.
 
> > > Here a solution for DOS/Windows which don't even use the
> > > advanced features of cmd.exe so it can also be executed
> > > in pure DOS.
>
> > > Now show us a much easier solution using bash/Linux.
> >
> > What the _fuck_ has linux got to do with a comparison between shells?
>
> Because this whole sub thread is about scripting in Unix/Linux
> using Unix-lile shells compared to scripting in Windows using
> command.com/cmd.exe.
 
When I stepped into the thread, it was simply a discussion about
the flexibility of bash, and no OS was mentioned. As I've said X+2 times
now. Every point that you made about bash that was incorrect I
corrected. If you are not precise enough to make statements about
bash in linux when you mean bash in linux then that's _your_ problem.
When I make statements about bash, I'm talking about the shell, nothing
else. If you interpreted my statements about bash to be statements
about bash in linux, then that's _your_ mistake. Get over it.
 
> > -- 8< --------------------------------------------------------------------
> > #!/bin/sh
> > umask 0
> > rm -f y_n.com
> > echo -e 'Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=\r'>y_n.com
> :
> > -- 8< --------------------------------------------------------------------
>
> > So, what was the flexibility advantage that batch files have over
> > bash scripts again?
>
> That will run only in DOS/Windows but we are speaking about
> the flexibility of unix-like scripts in Unix.

For the X+3rd time, WRONG.

> Come on, you
> told us:
> > Is 45 bytes not a small enough ELF executable for you?
>
> and this is an assembly group, so use your assembly skills and show
> us how easy it is to extend the ability of bash in Linux to allow
> a mouse click on a YES and NO button. As I have shown, 7 echo lines
> are sufficent in a DOS batch script (no extrnal program needed).
 
1) Are you prepared to pay me my professional rate for the work?

2a) Why do you think that comparing the size of OS-specific applications
tells anyone anything about the flexibility of scripts. You're working
in a toy OS which lets you have direct access to the screen and the mouse.
If you're permitting such OS-specific features, then I'd chose as mine
the use of a distribution that comes bundled with tcl/tk or perl/tk.
It's probably _way_ less than a 7 line script in either of those languages.

2b) If you like challenges, how about writing a 2 line Win/DOS batch
script that starts a UML (user mode linux) session? You see, you can't
do it because the task that has been selected is inherently OS (and in
your case, BIOS) specific.

Such challenges prove nothing. Grow up, Herbert.

> > You're ->this<- close to joining
> > The_Sage and alex the yepper in the killfile.
>
> After the logic you have presented in this thread, I'm not sure
> whether you are not The_Sage.

Yawn, the age old IKYABWAI defence. I've never seen that before.
At least not from someone your age.

Phil 

-- 
The gun is good. The penis is evil... Go forth and kill.