Backtick versus $()

[Chad Perrin]

On Thu, Feb 24, 2011 at 08:09:21PM -0430, Andres Perera wrote:
> On Thu, Feb 24, 2011 at 7:22 PM, Chad Perrin <perrin at apotheon.com> wrote:
> > On Thu, Feb 24, 2011 at 07:12:55PM -0430, Andres Perera wrote:
> >>
> >> the author of vi, who is also the author of csh regards it as poor code
> >
> > Good for him.
> 
> let's pretend you know better by addressing your stupid responses

Why are you such a troll?


> >>
> >> the parser is wonky and tcsh built uppon that code instead of basing
> >> their efforts on something solid
> >
> > I take it "wonky" is some technical term with which I am not familiar.
> 
> % if (0) echo > file
> % ls
> file
> 
> but of course, this is old as hell and was already linked by someone
> else in this thread
> 
> ie, you're dodging problems

I didn't dodge a problem.  I ignored something largely irrelevant to
interactive use that *you* didn't bring up, anyway.

Is that your only complaint about it being "wonky"?


> >>
> >> *you* are the one that's dodging questions
> >
> > Really?  What question did I dodge?  If you repeat it, and it is not
> > completely full of crap, I'll be happy to address it directly.

Good job.  Usually, you'd be more effective pretending I didn't call you
on something if you did not requote it.


> >>
> >> history expansion is in all the modern shells, so it's not a "csh
> >> thing" anymore, and hasn't been for a very long time
> >
> > What does that have to do with it?  I never said otherwise.
> 
> then what other feature in tcsh would leverage against modern shells?
> why do i have to ask you this given that the query was implied a long
> time ago by more than one person?

Why do you think "more features" automatically equals "better"?


> >>
> >> every feature in csh is present in other shells, barring repetition
> >> like ls-F (other ls(1) implement colors)
> >
> > I guess that depends on how you define "feature" -- but I don't use csh
> > without the t much, anyway, so that statement is not directly applicable
> > to the interactive shell I have been using most of the time.
> 
> actually, it does apply because ls-F is a tcsh builtin, not csh

No, it doesn't apply, because the "barring" clause is not the primary
clause of that statement.  The primary clause, and the point to which I
responded, was "every feature in csh is present in other shells".


> 
> do you even know the slightest thing about the shell you use?

Have you already forgotten what you, yourself, said -- even when you
quoted it back to me?  You said more than "ls-F".  I responded to that
"more".  I left the "ls-F" clause in there to preserve some context for
you.


> 
> this information isn't exactly hidden, on the contrary, it's right
> there in the manual
> 
> and before you even think about it, yes using both interchangeably is
> correct because in freebsd, csh is a link to tcsh

That doesn't make using the terms interchangeably "correct".  It just
makes it lazy.  If I execute a shell with "csh" it behaves differently
than if I execute it with "tcsh", which is relevant to discussions of
features it provides for interactive use.


> >
> > Also . . . feature counts are not measures of quality.
> 
> in a unix context, more features, specially those that overlap, are
> regarded as unwanted. no, i'm not going to explain orthogonality and
> its benefits to you -- it should be basic knowledge by now

My statement that feature counts are not measures of quality was in
reference to your brilliant statement above that csh is not as good as
other shells because they have all the (useful) features of csh, but
more.  I just questioned the value of "but more" in your implied
argument.

Thank you for reinforcing my argument for me.


> >
> > I'm not sure why you're bringing these things up.  "They both have
> > instances of the same basic mistake -- implementing functionality that
> > already exists in standard utilities."  Well, great.  I'm not sure how
> > that has anything to do with mksh being better in all ways.
> 
> since i pointed out more than feature overlap, this is a weak strawman

It's not a straw man.  It's a direct response to something *you* said.
If you want to concede this point, feel free -- but don't claim that the
fact you concede this point is proof that I'm not arguing "fairly"
somehow.


> >>
> >> it's clearly a different case, and the fact that you can't see this
> >> seems to indicate that you have no idea what you're talking about,
> >> like most of the people on this thread
> >
> > I have to wonder if you even understand your own arguments when you
> > say things like this.
> 
> what i can point out is that responding to each sentence out of context
> is very annoying. if ls-F being over-optimization recieves a "maybe so"
> qualification, then this is clearly a contradiction

I'm responding to each point as a point.  What am I supposed to do
instead -- just take your approach, never address any specifics, and
declare myself the winner?  No thanks, I don't want to descend to your
level of ineptitude at communicating with human beings.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20110225/fc7d382a/attachment.pgp