Re: "return" should not continue script execution, even if used inappropriately

> > | the "answers" have mostly been about "how to do this". > > Yes, that would be the point, wouldn't it? > no. a discussion thread can have multiple points. one point that arose was someone calling this technique (or python programmers, or both) crazy. that's the one i'm talking about, as i'

Re: "return" should not continue script execution, even if used inappropriately

> > This is also simple. He's just not listening to the answers that's not only an unwarranted personal attack, but it's untrue. the "answers" have mostly been about "how to do this". however as i've stated multiple times: i'm not asking how to do it, i'm explaining why this technique which i

Re: "return" should not continue script execution, even if used inappropriately

your code in a main function and deal with it. > > -- konsolebox/m > > On Mon, Jan 21, 2019, 12:39 PM Robert Elz >> Date:Sun, 20 Jan 2019 17:43:04 -0800 >> From:don fong >> Message-ID: < >> cahqakpxao-pbdr2e0tnhh_iouhlwdxq_fccbzo

Re: "return" should not continue script execution, even if used inappropriately

t; *From*: Greg Wooledge > *Subject*: Re: "return" should not continue script execution, even if used > inappropriately > *Date*: Mon, 21 Jan 2019 09:01:33 -0500 > -- > > On Sun, Jan 20, 2019 at 05:43:04PM -0800, don fong wrote: > >* i don't

Re: ${p+\"$p\"}

here is another possible workaround, apologies if this has already been mentioned. cat < wrote: > On Mon, Jan 21, 2019 at 09:14:26PM +0800, Dan Jacobson wrote: > > So how am I to get > > "A" > > with bash? > > > > $ cat z > > p=A > > cat < > ${p+\"$p\"} > > ${p+"$p"} > > EOF > > $ bash z > > \"A\

Re: "return" should not continue script execution, even if used inappropriately

stuff when dotted in; but call the main function (or some other function) when run at the top level. "sh -c '. script'" doesn't accomplish that. On Thu, Jan 10, 2019 at 2:53 PM Robert Elz wrote: > Date:Tue, 8 Jan 2019 23:40:40 -0800 > Fro

Re: Sourcing a script from a pipe is not reliable

interesting. it looks like somehow the ". /dev/stdin yes" side isn't waiting for the "echo echo '$1'" side to write to the pipe. in theory, you should be able to delay the echo and it should still work... (sleep 1; echo echo '$1') | . /dev/stdin yes but on my mac, adding the sleep makes it

Re: "return" should not continue script execution, even if used inappropriately

> > df...@dfong.com said: > | there's a good reason for the "craziness": it enables individual > testing of > | the script's functions. > > For that kind of use there's a trivial solution (as there often > is for cases when people are sure that the current definition > is inadequate). > to be

Re: "return" should not continue script execution, even if used inappropriately

> > Crazy python people. > there's a good reason for the "craziness": it enables individual testing of the script's functions. it's a good idea, and IMHO it should be more widely used in "production" shell scripts. On Mon, Jan 7, 2019 at 5:56 AM Greg Wooledge wrote: > On Mon, Jan 07, 2019 at 0

Re: Identical function names in bash source code

for my 2c, the post seems within the charter. quoting from the bug-bash info page: > This list distributes, to the active maintainers of BASH (the Bourne Again > SHell), bug reports and fixes for, and *suggestions for improvements in > BASH. *

Re: Add sleep builtin

wouldn't it be less confusing if the proposed built-in sleep function were given a new name instead of overloading "sleep"? On Tue, Aug 21, 2018 at 4:34 AM, konsolebox wrote: > On Tue, Aug 21, 2018 at 4:23 PM Ilkka Virta wrote: > > > > On 21.8. 02:35, Chet Ramey wrote: > > > I don't think ther

Re: misleading error message from variable modifier

will the coverage target be in an upcoming release? On Sat, Mar 17, 2018 at 7:13 PM, Chet Ramey wrote: > On 3/17/18 6:39 PM, don fong wrote: > > Chet, thanks for the tip about where to find the tests for subst.c . i > > still think that my tests cover some cases that ar

Re: misleading error message from variable modifier

target to do it. On Wed, Mar 14, 2018 at 7:08 PM, Chet Ramey wrote: > On 3/9/18 3:14 AM, don fong wrote: > > > > > my question was whether you have tests for the variable modifiers. > > i don't see any. that's the area of code i was touching, and that's why

Re: misleading error message from variable modifier

18 at 7:10 AM, Chet Ramey wrote: > On 3/7/18 1:00 PM, don fong wrote: > > Chet Ramey wrote: > >> What are the most important features that you consider to lack > unit tests? > > > > are there any tests that cover the variable modifiers, either unit tests > or

Re: misleading error message from variable modifier

e a unit test target in the Makefile. the "make tests" target mentioned in the INSTALL file, seems to do only functional tests. On Sun, Mar 4, 2018 at 1:59 PM, Chet Ramey wrote: > On 3/2/18 4:45 PM, don fong wrote: > > Chet, thanks for the explanation about CHANGES. i

Re: coding standards

s a first-time submitter, i'm feeling somewhat discouraged by alterations that i think lower the quality of the code, and especially by the dropped tests. i don't care so much about the formatting. On Tue, Mar 6, 2018 at 9:51 AM, L A Walsh wrote: > > > don fong wrote: &

Re: coding standards

e, check_nullness (as in my patch) instead of check_null (as in the altered version). On Sun, Mar 4, 2018 at 6:15 PM, Clark Wang wrote: > On Mon, Mar 5, 2018 at 9:13 AM, don fong wrote: > >> Clark, thanks for your answer. >> >> I use ``if (flag)''

Re: coding standards

uot;), name); + else + report_error (_("%s: parameter is not set"), name); +} On Sun, Mar 4, 2018 at 4:43 AM, Clark Wang wrote: > On Sun, Mar 4, 2018 at 5:15 AM, don fong wrote: > >> admittedly this is a very minor point, but i am curious. this has to do >> with c

coding standards

admittedly this is a very minor point, but i am curious. this has to do with coding standards for bash source. consider an if statement in C (or bash, for that matter). which is form is better? Form (A): if (flag) X(); else Y(); Form (B): if (flag == 0) Y(

Re: Unset array doesn't work

Robert Elz: > And yet when that change to the entrenched behaviour was made, > there were no complaints? And there's no option to switch back to > the previous way? Kind of suggests just how important everyone > believes the original method was, doesn't it? doesn't the same argument apply ev

Re: misleading error message from variable modifier

On Fri, Mar 2, 2018 at 12:21 PM, Chet Ramey wrote: > On 3/1/18 11:37 PM, don fong wrote: > > Chet, thanks. in subst.c there is code that looks similar to what i had > > suggested. but i don't see the tests that i submitted. i also don't see > > the change listed in CH

Re: misleading error message from variable modifier

Chet, thanks. in subst.c there is code that looks similar to what i had suggested. but i don't see the tests that i submitted. i also don't see the change listed in CHANGES? On Thu, Mar 1, 2018 at 11:09 AM, Chet Ramey wrote: > On 3/1/18 12:24 PM, don fong wrote: > &

Re: misleading error message from variable modifier

any feedback on this patch? On Sat, Feb 24, 2018 at 11:24 AM, Chet Ramey wrote: > On 2/23/18 10:20 PM, don fong wrote: > > hi folks. i'm a bash user, who just noticed a slight anomaly. it has > > to with the shell variable modifier ${parameter?} . according to the > &

Re: Unset array doesn't work

seems like it would be helpful to explain this behavior more clearly in the man page. On Wed, Feb 28, 2018 at 12:14 PM, Chet Ramey wrote: > On 2/28/18 3:00 PM, Greg Wooledge wrote: > > > Does unset create some kind of "placeholder" in the current function > > (but not in a caller)? > > Yes, t

Re: add generated files to .gitignore

Chet, thanks for the suggestion. i still wonder what's the objection to changing .gitignore? using a separate directory to build, while i'm working on the sources, feels less convenient. On Sun, Feb 25, 2018 at 1:10 PM, Chet Ramey wrote: > On 2/25/18 2:49 PM, don fong wrote:

Re: add generated files to .gitignore

irectory is the natural and most convenient way to do things. from what i've seen, it's also the way that "most" other open source software works. my proposed change to .gitignore will facilitate that mode of operation. what do you perceive as the drawback? On Sat,

Re: add generated files to .gitignore

Eric, thanks for the tip. my feeling is that regardless of whether these files are pushed, they clutter up the "git status" listing after i've done a build. On Sat, Feb 24, 2018 at 11:28 AM, Eric Blake wrote: > On 02/24/2018 01:26 PM, Chet Ramey wrote: >> >> On 2

add generated files to .gitignore

based on my experience creating one patch, running "make" and "make test", i found that "git status" was reporting a lot of generated and built files that i think should be ignored. i added the "untracked" files to .gitignore, and this is the patch. ign.patch Description: Binary data

Re: misleading error message from variable modifier

Clark, thanks for your response. i'm attaching my patch. On Fri, Feb 23, 2018 at 7:32 PM, Clark Wang wrote: > On Sat, Feb 24, 2018 at 11:20 AM, don fong wrote: >> >> >> i would like to submit this change for inclusion in bash. how should i >> proceed? > &

misleading error message from variable modifier

hi folks. i'm a bash user, who just noticed a slight anomaly. it has to with the shell variable modifier ${parameter?} . according to the man page, ${X?} should yield an error message and exit if X is unset, otherwise the value of X. in this case, unset X; echo ${X?} i expect to get an er