A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=767 ====================================================================== Reported By: dwheeler Assigned To: ajosey ====================================================================== Project: 1003.1(2008)/Issue 7 Issue ID: 767 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: Under Review Name: David A. Wheeler Organization: User Reference: Section: XCU 2.14 (local) Page Number: 2374 Line Number: 75650 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2013-10-11 02:02 UTC Last Modified: 2017-05-23 22:54 UTC ====================================================================== Summary: Add built-in "local" ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0000771 Expose alternate shell function usage t... related to 0000465 is the list of special built-ins exhaus... related to 0001025 set description contains counterproduct... ======================================================================
---------------------------------------------------------------------- (0003730) kre (reporter) - 2017-05-23 22:54 http://austingroupbugs.net/view.php?id=767#c3730 ---------------------------------------------------------------------- Re: Note: 0003715 So your model is rather than `local x' creating a new instance of x, which remains unset until explicitly assigned a value, `local x' is equivalent to `local x="$x"'. Approximately, though the question of the initial value is not the important issue here, the "rather than" part I most agree with is "creating a new instance of x". Whether the value of x after "local x" is unset, or unchanged from the value it had immediately before the "local" command was performed is of less importance - both schemes have their advantages for different applications, and I can see the benefit of creating a pair of flags for local (say "local [-ux] var[=[value]]..." as a synopsis - and leaving aside "local -" for now) where -u implies "unset vars not explicitly given a value" and -x means "use existing value for var is not overridden, and the default could be implementation defined. I think I might even implement that (and make the "implementation defined" be a "set" option which in my case would default to the -x case). (The options to "local" I have just done, works fine... a shell option I'll consider later.) Re: Note: 0003724 > If calling "unset" pops such a variable instance, you would see the > previous instance that may be the instance from another function call > instead of the global value and I doubt that this is what users like > to see. This is just the dynamic vs. static scoping issue. Not really, those are separate issues, the real question is whether "unset" actually destroys all knowledge of the variables named (assuming it works, ie: ignoring variables that are readonly) or whether it merely removes the value (no point keeping it, as the only way to get out of unset state is to give the var some new value) and marks it as unset. The differnce occurs when the variable has some other attribute. In the standard, there is only one that matters - export (as once readonly the var cannot be unset), so the difference is illustrated by this example, where there is no issue of scoping at all (no functions at all, just code and globals). Assuming that here, X is a totally unknown variable, never before referenced in any way, not imported from the environment, and not one of the vars defined by the shell as being set at init time. export X At this point, the variable X is given the export status, I think we all agree on that, though as it is still unset, it does not appear in the environment. X=string now X becomes set, and is added to the environment. unset X now X is unset again, and is removed from the environment. X=new-value OK, now we get to the question, X is set again at this point, but what about the environment, is it still exported or not? POSIX does not say, one way or the other as best I can see (though as always, the caveat about it being difficult to be sure what is not said, as there might always be somewhere that I did not think to look...) In our shell, we have export -x X which explicitly removes the export attribute from X, so "unset" does not need to do that (though we also have an option for unset as well), all it needs to do is remove the value, make the variable be unset. I see this as a clean, orthogonal, model of how things should behave. On the other hand, if you are of the view that "unset" must obliterate all memory of X ever existing, then the export atribute necessarily vanishes with it, and would need to be restored later if desired. This latter view would also allow the "local x; unset x" combination as having "unset x" just remove the newly created x and immediately restore the value that existed before "local x", whereas the "just remove the value" model does not admit that possibility. Re: Note: 0003729 We're talking how shells are implementing it, We shouldn't be, or no at that level of detail - the model that is implemened, or stated another way, the effect of the command, in various shells is something to be considered. How any of them actually makes that effect happen is irrelevant. this way mimics how compilers set up the stack frame for a function invocation, And in any case, I kind of doubt that any shell is implementing anything that way (at least for traditional compilers of traditional languages - if you're considering something like lisp on the other hand, maybe.) If a script inherits values with local a sequence like: unset foo; readonly foo; f() { local foo; foo=$IFS; }; should produce a name not found, or name not localizable error; since it would also inherit the "do not set this name" attribute of foo when trying to inherit the value. Definitely not "name not found", but an error, yes, and both bash and ash derived shells generate an error for this. bash on the "local" of a readonly var. We don't object to that, but the local variable (whose value has been saved) is still readonly si the attempt to assign to it fails. kre Issue History Date Modified Username Field Change ====================================================================== 2013-10-11 02:02 dwheeler New Issue 2013-10-11 02:02 dwheeler Status New => Under Review 2013-10-11 02:02 dwheeler Assigned To => ajosey 2013-10-11 02:02 dwheeler Name => David A. Wheeler 2013-10-11 02:02 dwheeler Section => XCU 2.14 (local) 2013-10-11 02:02 dwheeler Page Number => 2374 2013-10-11 02:02 dwheeler Line Number => 75650 2013-10-11 08:31 geoffclare Relationship added related to 0000465 2013-10-15 22:47 dwheeler Note Added: 0001912 2013-10-17 05:52 ranjit Note Added: 0001924 2013-10-20 05:00 shware_systems Note Added: 0001937 2013-11-14 16:08 geoffclare Relationship added related to 0000771 2015-04-23 23:12 emaste Issue Monitored: emaste 2016-07-05 09:35 joerg Note Added: 0003285 2016-12-01 16:51 eblake Relationship added related to 0001025 2017-05-19 21:39 mirabilos Note Added: 0003699 2017-05-19 22:12 stephane Note Added: 0003701 2017-05-22 11:19 joerg Note Added: 0003702 2017-05-22 11:20 joerg Note Edited: 0003702 2017-05-22 11:20 joerg Note Edited: 0003702 2017-05-22 11:21 joerg Note Edited: 0003702 2017-05-22 19:38 stephane Note Added: 0003703 2017-05-22 23:06 shware_systems Note Added: 0003704 2017-05-23 03:41 kre Note Added: 0003705 2017-05-23 10:47 shware_systems Note Added: 0003706 2017-05-23 11:07 shware_systems Note Edited: 0003706 2017-05-23 12:06 stephane Note Added: 0003707 2017-05-23 13:08 joerg Note Added: 0003708 2017-05-23 13:18 joerg Note Added: 0003709 2017-05-23 13:19 joerg Note Edited: 0003709 2017-05-23 13:41 chet_ramey Note Added: 0003710 2017-05-23 13:47 joerg Note Added: 0003711 2017-05-23 13:47 chet_ramey Note Added: 0003712 2017-05-23 13:51 joerg Note Added: 0003713 2017-05-23 14:00 chet_ramey Note Added: 0003714 2017-05-23 14:05 chet_ramey Note Added: 0003715 2017-05-23 14:11 stephane Note Added: 0003716 2017-05-23 14:14 chet_ramey Note Added: 0003717 2017-05-23 14:17 joerg Note Added: 0003718 2017-05-23 14:19 stephane Note Added: 0003719 2017-05-23 14:26 chet_ramey Note Added: 0003720 2017-05-23 14:29 chet_ramey Note Added: 0003721 2017-05-23 14:32 chet_ramey Note Added: 0003722 2017-05-23 14:45 joerg Note Added: 0003723 2017-05-23 15:16 chet_ramey Note Added: 0003724 2017-05-23 15:29 stephane Note Added: 0003725 2017-05-23 16:34 shware_systems Note Added: 0003726 2017-05-23 17:28 shware_systems Note Added: 0003727 2017-05-23 17:43 chet_ramey Note Added: 0003728 2017-05-23 18:49 shware_systems Note Added: 0003729 2017-05-23 22:54 kre Note Added: 0003730 ======================================================================
