bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature Request: Custom delimeter for single quotes


From: Eli Schwartz
Subject: Re: Feature Request: Custom delimeter for single quotes
Date: Sun, 3 Nov 2019 11:10:44 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0

On 11/3/19 3:15 AM, L A Walsh wrote:
> Reading your responses, first you tell him he's wrong for combining
> languages and try to get him to change that.

I offered the recommendation that introducing multiple languages without
a good reason is maybe a bit too much context switching.

I also told him he's wrong for adding in an additional language if that
additional language is not going to actually be used.

> Then you tell him his thinking is incorrect in wanting to use shell in
> the first place, and bring in FUD for not writing a secure solution
> in the first place (weren't they looking for _any_ solution to start
> with?).  That was followed by more FUD with the specter of poor
> performance (maybe on cygwin),

Both are valid reasons to want to avoid evaluating unknown input as
programming language metacharacters.

- Secure solutions are solutions which do not die on syntax errors if
  userdata is treated as programming language metacharacters.
- Secure solutions are also solutions which don't introduce code
  execution by untrusted users, in the event you don't trust the user.

- Using fast things instead of slow things is generally good, and
  especially good when there are no downsides. I have no idea what the
  speed of anything is on cygwin, but I'm not super fond of utterly
  wasteful waste on Linux systems either.

> ignoring basic SW development
> priorities of _first_ getting to a working prototype.

But my suggestion was that it is easier to get a working prototype if
you stop adding in artificial complications, like "it must be evaled in
a /bin/sh subprocess".

> I neglected to catch your submitted solution, BTW, only critique.

I did in fact offer a solution. I offered three of them. What I didn't
offer was the ruby glue code component, because I am not a ruby user and
this is a bash mailing list, so why *should* I know ruby? On the other
hand, you did not submit a solution for the ruby side of things either.

>> ... once you have a usercmd variable, why do you need
>> to printf it into another variable in order to run it ...
> ----
> Oh, I dunno, but sometimes, I like to print things out before
> I execute them, random stuff like that.  I tend to put things
> in variables in between steps and leave optimization till later.

But you can just print $usercmd. You can run it in eval, too. Did you
actually read what I wrote?

>> Given many fine answers were already suggested in this thread
> ---
>     Oh look, Patrick already came up with a similar answer -- and
> you already judge it as 'fine',

Yes, using a shellescape library is a fine answer, assuming that running
/bin/sh is actually a requirement. Avoiding the use of /bin/sh entirely
is a fine optimization, too (and I encourage this optimization).

> so I'll take that as a compliment
> on mine as well, 

You did not propose a shellescape library, do not consider yourself
complimented.

> compared to your...oh, that's right, you didn't
> propose an answer, you just criticized others.  I see that spot --
> not putting stuff out there to avoid criticism, while showing off your
> knowledge criticizing other people's work.  Nice safe way to feel good
> about yourself while congratulating yourself on showing those other
> know-nothings your stuff.

O....kay?

>> , can we
>> avoid proposing new ones which are both terrible and terrible failures
>> at even being cursorily tested?
>>   
> ----
>     You haven't proposed any yet,

Interesting definition for the word "three".

> but thanks to your feedback, the poster
> does have another working example to draw from.  You should try it sometime,
> though warning, it is hard trying to please others, some people will go out
> of their way to shoot others down...

No, just the ones who have a well-known, lengthily historic trend of
e.g. saying things that infuriate greycat as well.

Other people, I just have strong opinions at, like the strong opinion "I
think you would be better served by skipping the /bin/sh stuff if you
don't need it and don't use it".

If you're going to define "shooting others down" as "tries to propose
alternative solutions", i.e. "instead of doing X, have you considered
whether Y is actually a better fit for you", then I'm quite confident
this conversation will be impossible to continue in any reasonable manner.

Then again, your previous history on the archives for this mailing list
implies that is probably the case either way. :)

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]