Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Eli Schwartz <eschwartz@archlinux.org>
Newsgroups: gnu.bash.bug
Subject: Re: Feature Request: Custom delimeter for single quotes
Date: Sun, 3 Nov 2019 11:10:44 -0500
Lines: 162
Approved: bug-bash@gnu.org
Message-ID: <mailman.522.1572797460.13325.bug-bash@gnu.org>
References: <CAOnw=2J6fse6U=6zofMW7pORp0yTere_DYYSKGS6hf5xK2PuQA@mail.gmail.com> <5DBE6EF9.2000309@tlinx.org> <20421118-fb8b-531a-8dfa-bdb53ebb1a95@archlinux.org> <5DBE8CA6.1050800@tlinx.org> <da5a362e-b7b3-d618-9438-b70350095713@archlinux.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TWpOYOL87X0QposD5Hik0YwlTnVHBTZp7"
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0
In-Reply-To: <5DBE8CA6.1050800@tlinx.org>
Precedence: list
Xref: csiph.com gnu.bash.bug:15564

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--TWpOYOL87X0QposD5Hik0YwlTnVHBTZp7
Content-Type: multipart/mixed; boundary="2WvHD4a6ATHZcfwKrXpdKTxWDM5I8FDNs"

--2WvHD4a6ATHZcfwKrXpdKTxWDM5I8FDNs
Content-Type: text/plain; charset=utf-8
Content-Language: en-US-large
Content-Transfer-Encoding: quoted-printable

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,=20

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?
>>  =20
> ----
>     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 some=
time,
> 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=
=2E

Then again, your previous history on the archives for this mailing list
implies that is probably the case either way. :)

--=20
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


--2WvHD4a6ATHZcfwKrXpdKTxWDM5I8FDNs--

--TWpOYOL87X0QposD5Hik0YwlTnVHBTZp7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEvSewel70XCra9w4EhIGKaBmvSpsFAl2+/AUACgkQhIGKaBmv
Sps29RAApHasKzJf+K0oIdsjbWJ+LJETxgjVH4wfBhgceYbKdJgKOCQEcWAJfDS6
dkOh3TORuGXoLQ/1qzJG9l3Wyd+e+4zY3cLLaTlibKJ8yNq/Jyay0QbhlVCwFX7q
qt31ZeQ/BvPvAWhJRkQ5qVp3wH6YhK56wfZQpbqJO9gTyu/v5KN7y06IBRshdyga
yTJ9Rudbo/7LXzP83jqm1svFGMey58AFvTbrmtC3tpD+mL78UfH9kC2Rp3TbQOCE
0eMIfiUC2BxNwyA6QiSKKeq5hNz6gn9LLWUbA4ycr5aS7D/Pw6bnwZ/6ttwnQoZM
eRc/FhLpJHTOw1zFFyyUwZ9GIf3uCs0VvglBiJThzILHtdwNCrfjSYoX2gxnRzv/
RLL4WwTsIbr2xIW+Vtm6SjLPwE98NwBGEHMM9IDtQpHynjknhjLXp4huaipoXfwc
/o6SNPDZpoE4p9AIjPU6JmivN0S6IxFoEBu/oSybx5h9u5+uNvWmQJBIe4cxnU2W
HUjVEdprLKscPO5VQEpsTzIejoliBUFlD6oJTXSUZXsS6Pe0K3q+LpI+oNW07/4m
9XKKA7WxvvqkRThPLg+pT/vk6AwVjrGEipAepUT0CcHcUdSP+VvBGNeRzJikGGlZ
ig+rHo2X/L7HWEHdAI/vcHirYLB7/154L162jwMGFUFnPNyR3fuJAjMEAQEKAB0W
IQRgQRMEwJ02YoNA7v/OsWfvtXIr1gUCXb78BQAKCRDOsWfvtXIr1o55EACRd+ik
HKhgiqQXHwKprbKACBExjQcLFhWA8HtZ4cXqB0NTVTSaiLh/xYspKzhRqfpNGAjM
C/uMYLvmwOfLGRRnz4FJ2E+p9SFtmdd9pCbdCyGNwn8t6NjofFL3hAAnQlejFE4V
J/1lShrrtL8980VZBqOA2sXnvhsXxn95Mf40CuiORKJez2teeA+N2BRfmoKmafnB
APdTfdGmiAWSX5JBgNFkErGn8+N//sg180xUitnu9+NsO4ENgwYCypOctWjCUUL3
CUr8Jp8qV/Q0rH09kH4saHR21hcaOc5CJn7jkJM9a1UJioQe89aCfWvnVJ+HqbHH
FzmdD3My9NwQ7cp13XDUC1W6Wx6ynOm7fBsEWgejKyE5V3Fl0VBgECIYy2FdUUx9
9TfAfm2GL7LFevXsSzlDc9AGp3FokZBMCIAriAZtrMQCCsQ/rV0hi1BCpI8tdhtg
z1GISZo9vl2HqsFqO4O9dcGorwEHmD00zGsyjeandUDfy0GoYyEALSbjb6xkD+Q3
izfkYt1ofUL4fCOrvK773l21OBam+02W87T76mmhfYyLc1fxxpbaJeeV8/BSQsQk
7xPAK3VDiSVpPKZ5MwMoi+7B4qhxkd+HXFoebrAaanpvNHy0wX2CBn+Zq17JRnWz
Qv3W9dM+gVURdGI1pm3zIrjREJ+300PLnXP32A==
=AMb3
-----END PGP SIGNATURE-----

--TWpOYOL87X0QposD5Hik0YwlTnVHBTZp7--