Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #15561 > unrolled thread

Re: Feature Request: Custom delimeter for single quotes

Started byEli Schwartz <eschwartz@archlinux.org>
First post2019-11-03 01:31 -0500
Last post2019-11-03 01:31 -0500
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Feature Request: Custom delimeter for single quotes Eli Schwartz <eschwartz@archlinux.org> - 2019-11-03 01:31 -0500

#15561 — Re: Feature Request: Custom delimeter for single quotes

FromEli Schwartz <eschwartz@archlinux.org>
Date2019-11-03 01:31 -0500
SubjectRe: Feature Request: Custom delimeter for single quotes
Message-ID<mailman.488.1572762722.13325.bug-bash@gnu.org>

[Multipart message — attachments visible in raw view] — view raw

On 11/3/19 1:08 AM, L A Walsh wrote:
> I can't say for certain, but is there any reason why this wouldn't
> work?  As long as the user input doesn't match the generated uuid,
> it should be hard to match it as a delimiter...
> 
> I am probably missing something obvious, but this would seem to
> solve your problem, no?
> 
> 
> 
> read usercmd       # or whatever/however you get the command
> 
> delim=$(uuidgen)
> printf -v cmd "sh -c <<'%s'\n%s\n%s\n" "$delim" "$usercmd" "$delim"
> eval $cmd

Leaving aside all the many many MANY problems with what you jokingly
call "shellscripts"... once you have a usercmd variable, why do you need
to printf it into another variable in order to run it (in your existing
shell) via sh -c *AND* eval, with the end result of... evaluating
usercmd, no more, no less?

At any rate, your proposal is simply a syntax error, for two reasons:
- sh -c expects a string, not a stdin redirection
- eval must take a quoted variable in order to correctly handle
  variables with embedded newlines

Given many fine answers were already suggested in this thread, can we
avoid proposing new ones which are both terrible and terrible failures
at even being cursorily tested?

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web