From: Francesco R <vivo@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] lights on internals
Date: Mon, 03 Oct 2005 11:40:36 +0200 [thread overview]
Message-ID: <4340FC94.8090101@gentoo.org> (raw)
In-Reply-To: <20051003064252.GE27872@nightcrawler>
Brian Harring wrote:
>On Sun, Oct 02, 2005 at 11:07:13PM +0200, Francesco R wrote:
>
>
>>The ready to cut ebuild at the bottom print it's environment (variable
>>and functions) to a bunch of files into /var/tmp/fakebuild/.
>>May be useful for who want to have a look at "what" and "when" is
>>avaible during the various emerge phases (but not limited to).
>>print_env() {
>> local fakebuild_output_dir="/var/tmp/fakebuild"
>> mkdir -p "${fakebuild_output_dir}" || die
>>
>> [[ -z "${fakebuild_progr}" ]] && fakebuild_progr=100
>> fakebuild_progr=$(( $fakebuild_progr +1 ))
>> export fakebuild_progr
>>
>> local fakebuild_ext="${1}.${fakebuild_progr}"
>>
>> # not sorting, break multiline vars
>> einfo "${fakebuild_output_dir}/env_${fakebuild_ext}"
>> env \
>> &> "${fakebuild_output_dir}/env_${fakebuild_ext}"
>>
>> # Remove egrep and sort to see the source of every fx
>> einfo "${fakebuild_output_dir}/fxlist_${fakebuild_ext}"
>> typeset \
>> | egrep '^\b.* \(\)' \
>> | sort \
>> &> "${fakebuild_output_dir}/fxlist_${fakebuild_ext}"
>>}
>>
>>
>
>This won't work as you expect. Env is a binary, it only gets
>the exported env.
>
>
>
Got the point (maybe), "typeset" is a Bash built-in.
The first part of the "typeset" output command give the variable list
*and* it's different from the output of "env" binary.
The output is different in two ways, first the vars are differently
formatted, missing apices " ' " for example.
env also is missing all .bashrc defined vars (speaking of a normal
environment not of a portage/emerge one).
==> the "env" command should be replaced by
typeset &> tmpfile
tmpfile | grep -B10000 "$(egrep "^\b.* \(\)" tmpfile | head -n 1)" |
head -n '-1'
(basically the output of typeset cutted at first function)
>Elaborate on the "what and when" bit also, since the env that's dumped
>to ebuild.sh varies depending on a lot of things.
>~harring
>
>
>
The environment is changing between the various predefined functions and
in the global scope of an ebuild, at the moment only for vars, not for
functions.
example of variable vars are:
SANDBOX_*
PORTAGE_RESTRICT
TMP
EBUILD_PHASE
TMPDIR
PWORKDIR
DISTCC_DIR
LD_PRELOAD
All variables that must stay readonly, or not readed at all, inside an
ebuild but may explain at the human that's writing one, what's happening
and when.
better ?
--
gentoo-dev@gentoo.org mailing list
prev parent reply other threads:[~2011-10-31 3:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-02 21:07 [gentoo-dev] lights on internals Francesco R
2005-10-03 6:42 ` Brian Harring
2005-10-03 9:40 ` Francesco R [this message]
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=4340FC94.8090101@gentoo.org \
--to=vivo@gentoo.org \
--cc=gentoo-dev@lists.gentoo.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox