Re: Preventing Bash Variable Confusion

On Thu, 30 Jan 2020, Roger wrote: They still allow you to define constants in all-caps. The impact it makes is not so different with defining globals as such. Try Ruby. The reason I used to prefer using all uppercase/capital letters, the variable definitations would stand out similar to C st

Re: Preventing Bash Variable Confusion

>They still allow you to define constants in all-caps. The impact it >makes is not so different with defining globals as such. Try Ruby. The reason I used to prefer using all uppercase/capital letters, the variable definitations would stand out similar to C style definition macros. Variables

Re: Preventing Bash Variable Confusion

On Wed, 29 Jan 2020, Chet Ramey wrote: On 1/29/20 2:05 PM, Roger wrote: "Linux Shell Scripting with Bash." (Burtch) suggested using declare instead of local, due to local lacking the other switches declare provides. p262 (eg. declare can specify type of variable, such as integar only.) This

Re: Preventing Bash Variable Confusion

On Thu, Jan 30, 2020 at 11:37:26AM +0800, konsolebox wrote: > You can still use all caps on global variables just mind the internal > variables. Easier said than done. How many times have you had to diagnose someone's failing script, and it turned out the reason it was failing was because they us

Re: Preventing Bash Variable Confusion

Date:Wed, 29 Jan 2020 13:57:48 -0500 From:Greg Wooledge Message-ID: <20200129185748.gf1...@eeg.ccf.org> | A script is supposed to be a self-contained entity, as much as possible. | It isn't supposed to be part of some web of tangled dependencies. In general I agr

Re: Preventing Bash Variable Confusion

On Thu, Jan 30, 2020 at 2:40 PM Roger wrote: > 1) Using an underslash on all capitol variable names just looks ugly in my > opinion. If you mean adding an underscore prefix I agree. > 2) Prefixing variable names with the name of the script (or other lengthy > prefix) requires more characters I c

Re: Preventing Bash Variable Confusion

> On Thu, Jan 30, 2020 at 11:37:26AM +0800, konsolebox wrote: > > Here's my take. > You can still use all caps on global variables just mind the internal > variables. You can have it prefixed by an underscore if you worry about > conflicts.** You can also have it prefixed with the script's

Re: Preventing Bash Variable Confusion

On Wed, Jan 29, 2020, 05:02 Roger wrote: > Anybody have any further insight concerning variable naming styles aside > from > what's already written within the documentation? > > I could do something like MY_VARIABLE, but then prefixing with "MY_" eats > up > three more chars I could have used for

Re: Preventing Bash Variable Confusion

> On Wed, Jan 29, 2020 at 02:24:11PM -0500, Chet Ramey wrote: >On 1/29/20 2:05 PM, Roger wrote: > >> "Linux Shell Scripting with Bash." (Burtch) suggested using declare instead >> of >> local, due to local lacking the other switches declare provides. p262 (eg. >> declare can specify type of var

Re: Preventing Bash Variable Confusion

On 1/29/20 2:05 PM, Roger wrote: > "Linux Shell Scripting with Bash." (Burtch) suggested using declare instead > of > local, due to local lacking the other switches declare provides. p262 (eg. > declare can specify type of variable, such as integar only.) This is just wrong. `local' accepts t

Re: Preventing Bash Variable Confusion

> On Thu, Jan 30, 2020 at 01:03:31AM +0700, Robert Elz wrote: >Date:Wed, 29 Jan 2020 09:23:05 -0500 >From:Greg Wooledge >Message-ID: <20200129142305.gx1...@eeg.ccf.org> > > | As far as functions go, bash allows you to define local variables within > | a function. Th

Re: Preventing Bash Variable Confusion

On Thu, Jan 30, 2020 at 01:03:31AM +0700, Robert Elz wrote: > It actually doesn't, or not generally - it allows the function to avoid > namespace collisions with random globals (or other locals) that might exist > up the call stack, but doesn't prevent functions that are called from > trampling all

Re: Preventing Bash Variable Confusion

Date:Wed, 29 Jan 2020 09:23:05 -0500 From:Greg Wooledge Message-ID: <20200129142305.gx1...@eeg.ccf.org> | As far as functions go, bash allows you to define local variables within | a function. This avoids namespace collisions as long as you're within | that fun

Re: Preventing Bash Variable Confusion

Awesome. So $mVARIABLE is an alternative. However, per Google style and my preference, mixed seems messy. I thought camel/mixed case increased readability years ago, but over time I typed my_variable or my_function_name (C code) much easier as well as read easier. The missing space char betw

Re: Preventing Bash Variable Confusion

On 1/29/20 9:23 AM, Greg Wooledge wrote: > As long as you use at least one lowercase letter in your variable name, > you are guaranteed not to conflict with any internal shell variables. As long as you use mixed case. There are two lowercase shell variables bash looks at: auto_resume and histchar

Re: Preventing Bash Variable Confusion

On Wed, 29 Jan 2020, Greg Wooledge wrote: As long as you use at least one lowercase letter in your variable name, you are guaranteed not to conflict with any internal shell variables. Except for auto_resume and histchars. -- Chris F.A. Johnson

Re: Preventing Bash Variable Confusion

On Wed, Jan 29, 2020 at 12:57:41PM +0700, Robert Elz wrote: > Incidentally, since sh (all implementations, including bash) has a global > variable namespace, the biggest source of variable name conflicts is > usually with other sh scripts (functions, startup files, > environment variables...) that

Re: Preventing Bash Variable Confusion

Date:Tue, 28 Jan 2020 16:02:25 -0500 From:Roger Message-ID: <20200128210225.GC12574@localhost4.local> | 1) Bash internal reserved words cannot be used a variables. No such rule. Vars are always assigned using xxx= (no reserved words contain an '=') and accessed u