From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: typeset -p output gives shows variables which can't be read back in
Date: Sun, 27 Feb 2011 13:01:32 -0800 [thread overview]
Message-ID: <110227130132.ZM4792@torch.brasslantern.com> (raw)
In-Reply-To: <AANLkTimGfVca_t+dwpvvoVWyca+NzOTAn7z1MLqJdXxF@mail.gmail.com>
On Feb 27, 6:44am, Rocky Bernstein wrote:
}
} A little bit of context of why I am doing this. Recently in the zsh
} debugger I've added the ability to go into a nested zsh, and often one
} wants the existing environment of the debugged program preserved in
} this nested zsh.
You're kind of doomed here from the start. If the debugger is inside
a shell function, for example, you're never going to get scoping back.
} I would like to save to a file shell variables so that I can run a
} nested zsh and then read these back in. It is becoming a bit of a
} challenge because this in the output:
}
} typeset -i10 -r !=0
Hm, I'm a bit surprised the '!' isn't quoted there; but the real issue
is that you get "not an identifier" or the like for a number of those,
and "can't change type" for ones that come from zsh/parameter, plus a
few "read-only variable" complaints.
} typeset -ar '*'
Hmm, strange. That one does NOT give "not an identifier" ...
} *=()
... but that of course bombs with a globbing error.
} Failing a better solution, I think what I'll have to do is store IFS=''
} typeset -p into an array and check each item of the array.
The zsh/parameter module $parameters hash already tells you nearly all
you need to know. Something like this:
() {
local param type
for param type in "${(kv@)parameters}"
do
case "$type" in
(*local*) continue;; # Skip loop variables
(*export*) continue;; # No need to dump/restore if exported?
(*special*) continue;; # Maintained by the shell
(*readonly*) continue;;
(*) typeset -p "$param";;
esac
done
}
You can avoid zsh/parameter by parsing the output of "typeset +m +":
() {
local param type description
typeset +m + | while read -A description
do
param="${description[-1]}"
description[-1]=()
if (( ${#description} ))
then type="${description[*]}"
else type=scalar
fi
case "$type" in
(*local*) continue;; # Skip loop variables
(*export*) continue;; # No need to dump/restore if exported?
(*readonly*) continue;;
(*) typeset -p "$param";;
esac
done
}
However, that doesn't let you catch "special" parameters, though you
can still filter the readonly subset.
Note both of these techniques still miss things like:
typeset -T foo FOO
I.e., there's no way to discover by examination that an array and scalar
have been tied together.
} But then we come to the typeset -ar '*' line which I guess flows onto the
} next line.
Not exactly "flows", but for arrays and associative arrays (hashes) the
value can't be supplied in the typeset command, so an assignment line is
needed.
Also you may have to be careful with the order of assignments when you
read the file back in. Some assignments to special variables (like to
the "options" hash) might change shell behavior in unexpected ways.
next prev parent reply other threads:[~2011-02-27 21:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-27 11:44 Rocky Bernstein
2011-02-27 21:01 ` Bart Schaefer [this message]
2011-02-28 5:08 ` Rocky Bernstein
2011-02-28 7:09 ` Bart Schaefer
2011-03-01 3:09 ` Rocky Bernstein
2011-03-01 5:59 ` Bart Schaefer
2011-03-01 6:49 ` Rocky Bernstein
2011-03-01 15:15 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=110227130132.ZM4792@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).