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

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

  • Next message: SevagK: "Re: Announcing the" 
    Date: 28 Dec 2004 07:35:00 +0200

    Herbert Kleebauer <klee@unibwm.de> writes:
    > Phil Carmody wrote:
    > > Herbert Kleebauer <klee@unibwm.de> writes:
    >
    > > > Now, who is the wag/loon/crank (just quoting your words)?
    >
    > > You, still, it appears.
    > > The sensible thing would have been to just walk away.
    >
    > Are you speaking to yourself?
     
    Yes apparantly I am, as you're paying no attention at all.

     
    > > > After you got into a ded end with your
    > > > argumentation, you changed the subject and said you were
    > > > only comparing bash and batch scripting, but both in
    > > > DOS/Windows and not in Unix.
    > >
    > > Cite or retract. With that exact phrasing.
    >
    > No problem, but let' start with:

    You think you've found me saying that thoughout the whole thread the only
    thing I've been doing is comparing bash and batch scripting in Win/DOS,
    not unix...

    This'll be fun!
     

    > > Oh joy - the kook technique of out-of-context quotes. Let's go and
    > > see what the context is first...
    >
    > No out-of-context quotes. This quotes shows, that you were
    > speaking of shell programing in Unix/Linux compared to shell
    > programming in DOS/Windows:

    1) They were out of context quotes, as the quotes came with no context.
    2) I none of them to have I denied what my posts were about.
    but add to that:
    3) The context is you spreading misinformation.
    4) I was attempting to correct you.

    > > > ===================================================================
    >
    > > > Subject: Re: [ Attn: Randy ] Ad-hoc Parsing?
    > > > Date: 24 Dec 2004 21:25:07 +0200
    > > > Sender: phil@nonospaz.fatphil.org
    > > >
    > > > DOS batch files are no closer to the CPU than Unix shell scripts.
    >
    > Isn't this a compare of Unix and DOS shell scripts?

    Yes. That's because that's what you were talking about.

    However, like the troll or crank that you are, you've _removed_ the
    context that I put back in. That's _exceptionally_ impolite usenet behaviour.

     
    > > > Unix shell scripts calling other programs, which they often do,
    > > > is no different from DOS batch files calling other programs, which
    > > > they also often do.
    >
    > Isn't this a compare of Unix and DOS shell scripts?

    Yes. That's because that's what you were talking about.

    However, like the troll or crank that you are, you've _removed_ the
    context that I put back in. That's _exceptionally_ impolite usenet behaviour.
     

    > > > ===================================================================
    >
    > > > From: Phil Carmody <thefatphil_demunged@yahoo.co.uk>
    > > > Subject: Re: [ Attn: Randy ] Ad-hoc Parsing?
    > > > Date: 24 Dec 2004 21:45:53 +0200
    > > >
    > > > Therefore all writing to the "printer port" is simply writing to the
    > > > /dev/lp? files, which is an open(2), some write(2)s, and a close(2).
    > > > It makes no difference whether those syscalls are invoked from within
    > > > the shell or from your dropped program.
    >
    > Aren't you speaking about Unix/Linux here? There is no /dev/lp in DOS/
    > Windows.

    Yes. That's because that's what you were talking about.

    However, like the troll or crank that you are, you've _removed_ the
    context that I put back in. That's _exceptionally_ impolite usenet behaviour.
     
     
    > > > ===================================================================
    >
    > > > From: Phil Carmody <thefatphil_demunged@yahoo.co.uk>
    > > > Subject: Re: [ Attn: Randy ] Ad-hoc Parsing?
    > > > Date: 25 Dec 2004 07:48:15 +0200
    > > >
    > > > I agree the existance of a such raw binary format to be a potentially
    > > > useful feature in an OS. I also agree that Win32 and Linux executable
    > > > formats, as commonly produced by the usual tools, are unnecessarily
    > > > bloated for the production of exceptionally small tools. (e.g. the
    > > > 'true', 'false', and 'yes' executables in unix.)
    >
    > Aren't you speaking here about Linux and Windows and the existence
    > of a raw binary format in one of them?

    Yes. That's because that's what you were talking about.

    However, like the troll or crank that you are, you've _removed_ the
    context that I put back in. That's _exceptionally_ impolite usenet behaviour.
     
     
    > > > ===================================================================
    >
    > When you had to recognize, that all your arguments had been proven
    > wrong, you changed the subject and said you were only comparing
    > bash and batch scripting, but both in DOS/Windows and not in Unix.

    As you would have seen if you'd only read the context that I reinserted,
    and that you have removed -- which is _exceptionally_ impolite usenet
    behaviour -- at no point did I change the subject from one that you
    hadn't immediately prior to that spouted some nonsense about. As newbs
    read this group, I felt obliged to correct your nonsense.

    And not one of the above is me saying that the only thing I've been
    talking about in my whole contribution to that limb of the thread
    has been about bash and batch scripting, but both in DOS/Windows and
    not in Unix.

    It just so happens that the final bit of misinformation, oh *** it --
    that's too long a word, the final _lie_ that you spread was that
    bash couldn't drop and spawn a .com file. Well, guess fucking what --
    that means my response is going to be about bash being able to drop
    and spawn a .com file (when run under cygwin, that supports .com files).

    That's not "changing the subject", that's staying on the subject.
    Please learn the difference, of people will think you're another usenet kook.

    > Here your posting one day after the above posting:
    >
    > ===================================================================
    > From: Phil Carmody <thefatphil_demunged@yahoo.co.uk>
    > Subject: Re: [ Attn: Randy ] Ad-hoc Parsing?
    > Date: 26 Dec 2004 23:21:14 +0200
    >
    > > > > Yes, it can drop a .com file as easily as any other file.
    > > > > But the big difference is, that it can't execute the .com
    > > > > file.
    > > >
    > > > It can execute the .com file as easily as a command.com or cmd.exe batch file can.
    > >
    > > Is this true for any new Linux distribution.
    >
    > You really have a hard time detecting the subject of arguments, don't you?
    > It's a statement about _bash_, not about _linux_.
    >
    > Now you want to tell us, you have only spoken about bash in
    > Windows (so it can execute .com files) and not about bash
    > in Linux and that you didn't compare scripting in Linux with
    > scripting in Windows.

    Bull***. Still steaming, too, it appears.

    Where do I claim that I have _only_ spoken about bash in Windows, and
    not about bash in Linux? Cite or retract. AGAIN - and get it right this
    time (i.e. retract - you're citing ain't worth ***).

    Here's a clue "It's a statement about XXX" is an assertion about _one_
    _single_ _statement_ (slow enough for you?). It is therefore _not_,
    IN ANY WAY (loud enough for you?), an assertion about the entirity
    of my contribution to the limb of the thread.

    > Bash is the usual shell in cygwin, on windows (though others are
    > available, and they behave identically in this regard).
    >
    > The ability to recognise and execute .com files is strictly a DOS and
    > MS Windows (and OS2, clones, and emulators) one. I've never said otherwise.
    >
    > ===================================================================
    >
    >
    > > Just give up arguing Herbert, go back to coding, that's what you're
    > > good at. And I genuinely mean that, you're a good coder, but you're
    > > embarassing yourself presently.
    >
    > Maybe you should not discuss in written form. It's too
    > easy to prove you wrong, when the complete history of
    > the discussion is available.

    If I were to tally things, it would look like I've squashed about half
    a dozen of your misunderstandings, and then about a dozen of your _lies_
    regarding those misunderstandings.
     

    > But you should now make your final decision:
    >
    > 1. Did you only compare scripting in Windows, using either bash
    > or cmd.exe.

    Where needed:
    I have compared .com to .exe to elf binary.
    I have compared cmd/command to bash
    I have compared unix to Win/DOS
    I have compared userspace to kernel code in linux
    I'm a very versatile chappie.

    > Then we can stop any further discussing, because
    > then you also support my initial statement (which was the
    > beginning of this whole sub thread):
    >
    > "But they (unix scripts) can't be more flexible than
    > DOS/Windows batch scripts, where you can directly
    > insert processor instructions into the script. Anything
    > a computer can do, a DOS/Win batch script also can do."

    As it stands I disagree. Before I state why I wish to emphasize that
    this is the first time I have addressed this point, only Johannes,
    Percival and T.M. replied to it originally. I can't say I agree in
    full with either of the latter two's replies either.

    Your logic is a bit broken - is "where" supposed to imply that the
    feature that follows (you can directly...) is the reason that unix
    scripts can't be more flexible that batch scripts? I can only
    sensibly assume it is supposed to be the reason, but that makes it
    bad logic, as you can more easily make an executable dropper in
    the unix shells (sh/bash/csh/tcsh/zsh/ksh) as you can in batch
    files (due to vastly more powerful quoting behaviour).

    So I can't say I agree, but I am prepared to offer the following
    "reinterpretation" that if you were to have said, I would have
    agreed with:

    Given the ability for Win/DOS batch files to easily create small
    executables (such as .com files) on-the-fly, and given the range
    of things that can be done with such small executables, I (being
    Herbert) don't feel that the unix shells provide any additional
    functionality that I need.

    There is provably more functionality in the unix shells, this
    has been demonstrated to you (C's script for example, which only
    began to scratch the surface of what sh can do). However, for
    many or even most users, such functionality isn't required for
    the majority of jobs, so if you were to make the above statement
    you wouldn't be alone. Give the number of new converts to linux,
    you'd probably be in the majority.

    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.

    > 2. Or do you again change your mind, so your arguments
    > were in reference to unix scripting compared to
    > Windows scripting. In this case, feel free to repost
    > any of your arguments, which you think has not been
    > proven wrong so long.

    I've had to repost most of my arguments a couple of times already.
    I've even had to repost _yours_, as you seem to be in complete denial
    about the context in which my posts were made. And it was terribly
    poor ettiquette to remove the context that I reinserted.

    It appears you still have a shovel - you can either dig yourself out,
    or dig yourself further in. Your move.

    Phil 

    -- 
The gun is good. The penis is evil... Go forth and kill.
  • Next message: SevagK: "Re: Announcing the"
    • Quantcast