zsh-workers
 help / color / mirror / code / Atom feed
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.


  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).