Backtick versus $()

[Andres Perera]

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:
>> On Thu, Feb 24, 2011 at 6:54 PM, Chad Perrin <perrin at apotheon.com> wrote:
>> >
>> > So far, your complaints translate to "Well, sure, for every concrete
>> > (t)csh problem I've identified, mksh has similar problems, but it's
>> > better because I like it."
>>
>> you are an obtuse person
>
> You have an attitude problem.  I will only hold that against *you*,
> though, and not against your *argument*, just as soon as you present one
> that is worth the time I spent reading it.
>
>>
>> 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

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

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

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

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

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

another display of ignorance and big words without knowing about the subject

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

>
>
>>
>> what's the justification for ls-F according to the manual? "it's faster
>> than ls(1)", which amounts to nothing in modern times and is a clear
>> case of over-optimization
>
> Maybe so.
>
>
>>
>> what's the justification for cat builtin in mksh? the read builtin
>> partly implements it, so it doesn't even represent new code addition
>
> 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 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

a noob accidentaly a tcsh

>
> --
> Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
>