Re: Feature Request: Custom delimeter for single quotes
On 2019/11/02 23:31, Eli Schwartz wrote: > 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? 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". Sorry, but reading your responses in this thread had me more than a bit amused. I just typed in something off the top of my head -- no aliases or anything (OMG!), and directly into my email client as it was pushing it to get it to 4 lines even using an "intermediate variable" passed to eval. That, on top of introducing a very-unlikely-duplicable, randomly-generated, uuid-based 'delimiter', getting it to 4 lines was tough! I asked the _original poster_ if it would work for their use case, not whether or not you approved or could break it. I did say I wasn't certain about the solution and that I was probably missing something obvious. Certainly, there was no claim of it being idiot-proof. Reading your responses, first you tell him he's wrong for combining languages and try to get him to change that. 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), ignoring basic SW development priorities of _first_ getting to a working prototype. I neglected to catch your submitted solution, BTW, only critique. > ... 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. > 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', so I'll take that as a compliment on mine as well, 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. > , can we > avoid proposing new ones which are both terrible and terrible failures > at even being cursorily tested? > You haven't proposed any yet, 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... Cheers and may the Schwartz be with you!
Re: Issues with history substitution and its documentation
Two more documentation issues I have found are below. It appears that an empty substring event designator uses the string of the previous substring event designator if none is provided and does not find the event if there is no previous string. [root@localhost ~]# ls dos hello.c [root@localhost ~]# cat hello.c > /dev/nul [root@localhost ~]# echo !?s? echo ls ls [root@localhost ~]# echo !?? echo echo ls echo ls [root@localhost ~]# ls -al > /dev/nul [root@localhost ~]# echo !?? echo ls -al > /dev/nul [root@localhost ~]# echo s s [root@localhost ~]# echo !?? echo echo s echo s [root@localhost ~]# echo !?l? echo echo ls -al > /dev/nul [root@localhost ~]# echo !?? echo echo echo ls -al > /dev/nul [root@localhost ~]# bash [root@localhost ~]# echo !?? bash: !??: event not found This action is not documented. An empty "old" string in a substitute word modifier uses the previous "old" if none is given, but uses an empty string if new is empty. If there was no previous "old" string, an error is reported. [root@localhost ~]# echo f g i f g i [root@localhost ~]# echo !:s/g/k/ echo echo f k i echo f k i [root@localhost ~]# echo af ag ai af ag ai [root@localhost ~]# echo !:s/// echo echo af a ai echo af a ai [root@localhost ~]# echo bf bg bi bf bg bi [root@localhost ~]# echo !:s//1/ echo echo bf b1 bi echo bf b1 bi [root@localhost ~]# echo gf gg gi gf gg gi [root@localhost ~]# echo !:gs//2/ echo echo 2f 22 2i echo 2f 22 2i [root@localhost ~]# bash [root@localhost ~]# echo a b c a b c [root@localhost ~]# echo !:s//1/ bash: :s//1/: no previous substitution Again, this behavior is not documented. On Thu, Oct 10, 2019 at 10:35 PM Jim Monte wrote: > Hi, > > This bug report has been my first one for Bash. I have not found how to > check the status of the bug. Would you please provide this information? > > Below are a couple more issues I found. > > There is an inconsistency with the documentation and behavior of the ^ > word designator. According to documentation, it refers to the first > argument but does not require a ':' before it if it starts the word > designator. However, it does not act like the numerical word designator 1 > at the end of a range. > > [root@localhost ~]# echo a b c > a b c > [root@localhost ~]# echo !!:1-1 > echo a > a > [root@localhost ~]# echo a b c > a b c > [root@localhost ~]# echo !!:^-^ > echo a b^ > a b^ > > Also it is not explicitly documented that :- is equivalent to :0- > > [root@localhost ~]# echo a b c d > a b c d > [root@localhost ~]# echo !!:- > echo echo a b c > echo a b c > [root@localhost ~]# echo a b c d > a b c d > [root@localhost ~]# echo !!:0- > echo echo a b c > echo a b c > > > Jim Monte > > On Thu, Oct 3, 2019 at 6:19 PM Jim Monte wrote: > >> Hi All, >> >> Below are some issues I found with history substitution. I am duplicating >> its behavior in a somewhat different use, and found issues with the >> documentation and bugs as described. >> >> Jim Monte >> >> >> >> >> From: jim >> To: bug-bash@gnu.org >> Subject: Issues with history substitution and its documentation >> >> Configuration Information [Automatically generated, do not change]: >> Machine: x86_64 >> OS: linux-gnu >> Compiler: gcc >> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' >> -DCONF_OSTYPE='l$ >> uname output: Linux T5500-Ubuntu 4.18.0-22-generic #23~18.04.1-Ubuntu SMP >> Thu J$ >> Machine Type: x86_64-pc-linux-gnu >> >> Bash Version: 4.4 >> Patch Level: 19 >> Release Status: release >> >> Description: >> >> = >> Documentation of quick substitution is incorrect (or does not match >> behavior). >> >> I believe this issue is an error with the documentation of history >> "Quick Substitution" that has existed since the first snapshot available >> at >> web.archive.org in 2007 at >> >> >> https://web.archive.org/web/20071223174140/http://www.gnu.org/software/bash/manual/html_node/Event-Designators.html >> >> At the least it is true that bash does not behave as the documentation >> states, >> but it does act in a way that is more reasonable (to me) than what is >> written. >> >> The documentation states that ^string1^string2^ is equivalent to >> !!:s/string1/string2/. However, bash treats it as equivalent to >> !!:s^string1^string2^. >> >> jim@T5500-Ubuntu:~$ echo /a >> /a >> jim@T5500-Ubuntu:~$ ^/a^b^ >> echo b >> b >> jim@T5500-Ubuntu:~$ echo /a >> /a >> jim@T5500-Ubuntu:~$ !!:s//a/b/ >> echo ab/ >> ab/ >> jim@T5500-Ubuntu:~$ echo /a >> /a >> jim@T5500-Ubuntu:~$ !!:s^/a^b^ >> echo b >> b >> >> >> = >> Behavior of empty "old" string in a substitution is undefined. >> >> The earlier example also shows a related but different issue with the >> !!:s//a/b/ command, where the string to locate is empty. >> It causes /a to be replaced by a and the b/ is appended. >> >> But >> jim@T5500-Ubuntu:~$ echo ///a >> ///a >> jim@T5500-Ubuntu:~$ !
Re: Feature Request: Custom delimeter for single quotes
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. Okay? >> , 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 signature.asc Description: OpenPGP digital signature
