zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: 'export -p' lacks POSIX output
Date: Sun, 23 Oct 2016 09:47:00 -0700	[thread overview]
Message-ID: <161023094700.ZM3120@torch.brasslantern.com> (raw)
In-Reply-To: <2047d07f-c5c1-6b8f-3d2d-cfcc2c06b875@inlv.org>

On Oct 23,  2:00pm, Martijn Dekker wrote:
} Subject: Re: 'export -p' lacks POSIX output
}
} Op 22-10-16 om 20:24 schreef Bart Schaefer:
} > Would anyone object if this just happened all the time, rather than
} > depending on POSIXBUILTINS + "export"?
} 
} After the patch, variables with a non-scalar type get output such as:
} 
} export -i10 SHLVL=2
} 
} Option flags to 'export' other than -p are not POSIX, and POSIX
} specifies output without any flags for 'export -p'.

We may have to settle for incompatibility here.  As I mentioned, there
is no way (without either a large code change or introducing yet another
global variable [*]) for the code that prints the command name to know
whether "typeset -p", "declare -p", "export -p", etc. were used.  If the
non-string (note, integer is not non-scalar) flags are eliminated, the
state won't be properly reflected if the commands are re-input.

If you're writing a POSIX-compatible script you shouldn't declare anything
integer in the first place, should you?

} In any case, if the output needs to be conditional upon POSIXBUILTINS
} anyway, I reckon you might as well not change the behaviour at all if
} POSIXBUILTINS is not active.

The selection of the command name to print and the output of the type
dinstinction flags are in separate sections of the code, so that's not
really a concern.  I think the addition of -g for typeset of non-local
parameters in function scope is useful (waiting to hear if anyone has
objections) and that doesn't depend on POSIXBUILTINS.

[*] Of course if such a variable WERE introduced I could take advantage
of it in zsh/param/private.  I was trying to avoid invasive changes for
that module but if it's needed for other reasons I'd be less shy.


  reply	other threads:[~2016-10-23 16:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-22  3:02 Martijn Dekker
2016-10-22 18:24 ` Bart Schaefer
2016-10-23 12:00   ` Martijn Dekker
2016-10-23 16:47     ` Bart Schaefer [this message]
2016-10-24  8:33   ` Peter Stephenson
2016-10-28 21:00 ` exported unset variables [was: 'export -p' lacks POSIX output] Martijn Dekker
2016-10-28 21:31   ` Bart Schaefer
2016-10-28 21:48     ` Martijn Dekker
2016-10-29  0:18       ` Bart Schaefer
2016-10-29  8:11         ` Martijn Dekker
2016-10-29 18:09           ` Bart Schaefer
2016-10-29 18:43             ` Peter Stephenson
2016-10-29 19:05           ` Bart Schaefer
2016-10-29 20:20             ` interactive comments [was: exported unset variables] Martijn Dekker
2016-10-30  1:25               ` 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=161023094700.ZM3120@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).