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

From: Herbert Kleebauer (klee_at_unibwm.de)
Date: 12/29/04 

Date: Wed, 29 Dec 2004 23:23:39 +0100

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.

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 ....". This is simple wrong. Then you changed
your mind 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).

> > 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. I said, it "makes it practicable". 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.

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

> 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. A statement about bash has to be true
independent of the operating system.

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

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

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

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

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