zsh-workers
 help / color / mirror / code / Atom feed
* More warn_create_global warnings
@ 2015-12-30 14:20 Frank Terbeck
  2015-12-30 18:17 ` Peter Stephenson
  2015-12-31  0:49 ` Daniel Shahaf
  0 siblings, 2 replies; 5+ messages in thread
From: Frank Terbeck @ 2015-12-30 14:20 UTC (permalink / raw)
  To: zsh-workers

Hey workers!

With the new warn_create_global behaviour, here is another warning that
seems bogus:

zsh% foo() { setopt warncreateglobal extendedglob; local f=bar; : ${f:#(#b)b(*)}; }
zsh% foo
foo: array parameter match created globally in function foo
foo: array parameter mbegin created globally in function foo
foo: array parameter mend created globally in function foo


Do I have to mark those local before using back tracking? Or could those
maybe be created in local scope unless they already exist?


Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: More warn_create_global warnings
  2015-12-30 14:20 More warn_create_global warnings Frank Terbeck
@ 2015-12-30 18:17 ` Peter Stephenson
  2015-12-31  1:06   ` Bart Schaefer
  2015-12-31  0:49 ` Daniel Shahaf
  1 sibling, 1 reply; 5+ messages in thread
From: Peter Stephenson @ 2015-12-30 18:17 UTC (permalink / raw)
  To: zsh-workers

[still on my phone with limited bandwidth...] 

> Do I have to mark those local before using back tracking?

Yes, if you don't want a warning. 

>Or could those 
> maybe be created in local scope unless they already exist? 

We don't know what scope you need them in.  You might have a utility
function in a script that needs to pass them back. It would be extremely
annoying to have to unpick this when the lack of a local wasn't actually
a problem.

Automatically set variables like these are particularly susceptible to causing
problems if you don't get the local in the right place.  That's because
they can be used at multiple levels in various different ways.

By contrast, variable names you pick yourself are less likely to cause
problems.

So if you don't want a warning here, it could be a sign you don’t really
need the warnings at all.

pws

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: More warn_create_global warnings
  2015-12-30 14:20 More warn_create_global warnings Frank Terbeck
  2015-12-30 18:17 ` Peter Stephenson
@ 2015-12-31  0:49 ` Daniel Shahaf
  2015-12-31  1:27   ` Bart Schaefer
  1 sibling, 1 reply; 5+ messages in thread
From: Daniel Shahaf @ 2015-12-31  0:49 UTC (permalink / raw)
  To: zsh-workers; +Cc: Frank Terbeck

Frank Terbeck wrote on Wed, Dec 30, 2015 at 15:20:37 +0100:
> zsh% foo() { setopt warncreateglobal extendedglob; local f=bar; : ${f:#(#b)b(*)}; }
> zsh% foo
> foo: array parameter match created globally in function foo
> foo: array parameter mbegin created globally in function foo
> foo: array parameter mend created globally in function foo

You used to have to 'local' both mbegin,mend,match and MBEGIN,MEND,MATCH [1].
I'm not sure whether that's still the case in latest master (couldn't
reproduce it, but maybe I wasn't trying right).

Cheers,

Daniel


¹ https://github.com/zsh-users/zsh-syntax-highlighting/commit/d3deffbf46a45250a399bea86a66cbdd14e12edc


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: More warn_create_global warnings
  2015-12-30 18:17 ` Peter Stephenson
@ 2015-12-31  1:06   ` Bart Schaefer
  0 siblings, 0 replies; 5+ messages in thread
From: Bart Schaefer @ 2015-12-31  1:06 UTC (permalink / raw)
  To: zsh-workers

On Dec 30,  6:17pm, Peter Stephenson wrote:
}
} So if you don't want a warning here, it could be a sign you don't really
} need the warnings at all.

The problem has become one where user A wants the warning, user B does
not, but user A wants to run scripts/functions written by user B.

Sometimes "user B" is the zsh distribution, which hasn't been (and is
rather difficult to be) rigorously checked for undeclared locals.

Hopefully the change in commit 7611e78ad1a8edbfcb486b19d4cfbc969ce1e771
to cause "emulate" to reset WARN_CREATE_GLOBAL will make this less of
an issue, come 5.3 ... but it still means user B has to remember to
properly "emulate"-ify his functions.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: More warn_create_global warnings
  2015-12-31  0:49 ` Daniel Shahaf
@ 2015-12-31  1:27   ` Bart Schaefer
  0 siblings, 0 replies; 5+ messages in thread
From: Bart Schaefer @ 2015-12-31  1:27 UTC (permalink / raw)
  To: zsh-workers

On Dec 31, 12:49am, Daniel Shahaf wrote:
}
} You used to have to 'local' both mbegin,mend,match and MBEGIN,MEND,MATCH.
} I'm not sure whether that's still the case in latest master (couldn't
} reproduce it, but maybe I wasn't trying right).

Not exactly.

You need local for mbegin, mend, and match to use the (#b) glob flag.

You need it for MBEGIN, MEND, and MATCH to use the (#m) flag.

You need all six parameters declared local only if using both flags.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-12-31  1:27 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-30 14:20 More warn_create_global warnings Frank Terbeck
2015-12-30 18:17 ` Peter Stephenson
2015-12-31  1:06   ` Bart Schaefer
2015-12-31  0:49 ` Daniel Shahaf
2015-12-31  1:27   ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).