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: Protect Loop Execution with Traps

On Wed, Jan 29, 2020 at 03:19:07PM -0500, Roger wrote: > >sigint_handler() { > >trap - INT > >kill -INT $$ > >} > >trap sigint_handler INT > > One thing to note here, I tried inserting the "trap sigint_handler INT" prior > to the loop/for/while statement (or outside of the loop) and the t

Re: Protect Loop Execution with Traps

>sigint_handler() { >trap - INT >kill -INT $$ >} >trap sigint_handler INT One thing to note here, I tried inserting the "trap sigint_handler INT" prior to the loop/for/while statement (or outside of the loop) and the trap doesn't work as you state it does for yourself. I find I have to

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: Protect Loop Execution with Traps

> On Wed, Jan 29, 2020 at 09:33:52AM -0500, Greg Wooledge wrote: >On Wed, Jan 29, 2020 at 01:05:32PM +0700, Robert Elz wrote: >> and (with all respect to Gred) please avoid archaic uses, and use the >> commands as they're currently specified, while "trap - INT" and "trap INT" >> do the same thing,

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: read and inconsistent handling of trailing null field?

> On 2020 Jan 29 , at 10:30 a, Chet Ramey wrote: > > On 1/29/20 10:19 AM, Clint Hepner wrote: > >> Bash Version: 5.0 >> Patch Level: 11 >> Release Status: release >> >> Description: >> >> read seems to incorrectly drop a null field when performing word-splitting >> and more fields than var

Re: read and inconsistent handling of trailing null field?

On 1/29/20 10:19 AM, Clint Hepner wrote: > Bash Version: 5.0 > Patch Level: 11 > Release Status: release > > Description: > > read seems to incorrectly drop a null field when performing word-splitting > and more fields than variables. > > All the examples below use > > IFS== read

Re: read and inconsistent handling of trailing null field?

On Wed, Jan 29, 2020 at 10:19:55AM -0500, Clint Hepner wrote: > bash-5.0$ IFS== read -r n v <<< "name=var=" > bash-5.0$ echo "$v" > var https://mywiki.wooledge.org/BashPitfalls#pf47

read and inconsistent handling of trailing null field?

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin19.2.0 Compiler: gcc Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Darwin hemma.local 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1

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: Protect Loop Execution with Traps

On Wed, Jan 29, 2020 at 01:05:32PM +0700, Robert Elz wrote: > and (with all respect to Gred) please avoid archaic uses, and use the > commands as they're currently specified, while "trap - INT" and "trap INT" > do the same thing, the former is the standard way, similarly for > "kill -INT ..." and "

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