curiosity: 'typeset -xr' vs. 'export -r'

2022-12-11 Thread L A Walsh

 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'

2022-12-11 Thread Lawrence Velázquez
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'

2022-12-11 Thread Robert Elz
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