curiosity: 'typeset -xr' vs. 'export -r'
This is mostly a 'nit', but I noticed I had "typeset -xr" in one of my scripts to mean export+read-only and was wondering why "export -r" was disallowed (err message): bash: export: -r: invalid option export: usage: export [-fn] [name[=value] ...] or export -p This seems to be an unnecessary "make-wrong", no? I.e. would it cause some syntactic or semantic problem in bash, if it were allowed? I suppose one could create an alias (despite advice that functions are "better" -- in this case a function doesn't work). I'm using ':;' for PS1, so cut/paste works: PS1=':; ' :; Export () { :; typeset -x "$@" :; } :; Export -r foo_xr=1 :; typeset -p foo_xr -bash: typeset: foo_xr: not found # vs. alias implementation: :; alias Export='typeset -x ' :; Export -r al_foo_xr=1 :; typeset -p al_foo_xr declare -rx al_foo_xr="1" Please forgive the noise if this has already been addressed as my bash is not fully up to date. Thanks! -linda
Re: curiosity: 'typeset -xr' vs. 'export -r'
On Sun, Dec 11, 2022, at 9:37 PM, L A Walsh wrote: > I suppose one could create an alias (despite advice that > functions are "better" -- in this case a function doesn't work). > I'm using ':;' for PS1, so cut/paste works: > > PS1=':; ' > > :; Export () { > :; typeset -x "$@" > :; } > :; Export -r foo_xr=1 > > :; typeset -p foo_xr > -bash: typeset: foo_xr: not found This happens because "declare"/"typeset" creates local variables within functions. Using -g works around this... $ Export() { declare -gx "$@"; } $ Export -r foo=1 $ declare -p foo declare -rx foo="1" ...but now "Export" always creates global variables, rather than scoping as "declare" and your alias-based version does. On the other hand, "export" also creates global variables, so in a sense the workaround version is more consistent. $ f() { export "$@"; } $ f var=1 $ declare -p var declare -x var="1" -- vq
Re: curiosity: 'typeset -xr' vs. 'export -r'
Date:Sun, 11 Dec 2022 18:37:02 -0800 From:L A Walsh Message-ID: <639693ce.3060...@tlinx.org> | This seems to be an unnecessary "make-wrong", no? I.e. | would it cause some syntactic or semantic problem in bash, | if it were allowed? Not for me to say, but I doubt it. But it would be one more needless difference with very little benefit. And next you'd want readonly -x as yet another way to do the same thing. | I suppose one could create an alias (despite advice that | functions are "better" -- in this case a function doesn't work). They do, when used properly. | :; Export () { | :; typeset -x "$@" | :; } | :; Export -r foo_xr=1 | | :; typeset -p foo_xr | -bash: typeset: foo_xr: not found That's because typeset (declare) in a function makes local variables, even when you don't ask it to. I think that's a poor design (inherited from ksh, which had a non-shell-like design paradigm, more aiming to be a programming language). But bash has -g which instructs typeset/declare to make global instead of local vars. Add that and the function form works as you intended. And then if you want, the function can be extended to do more, which the alias cannot. kre