Hi Martin,
On 11/13/24 20:40, Martin D Kealey wrote:
If you need to separate the output of `set -x` from your script's other
output, consider setting BASH_XTRACEFD:
exec 3>> /path/to/xtrace-logfile.txt
BASH_XTRACEFD=3
set -x
source your_file
set +x
exec 3>&-
I didn't know about BASH_XTRACEF
On Thu, 7 Nov 2024, Chet Ramey wrote:
> y.tab.h isn't part of the devel branch, you need bison to build it, and
> it is included in the bash distributions. I see the problem here, though.
> I'll figure out a way to fix it that's compatible with it being included
> and not without too many releas
The disappearance of the variables that you export within your sourced file
is not a feature of the source command. That will happen to ANY command
that changes the shell's internal state, when run in a subshell.
The fact that pipeline components are implicitly run in subshells is
arguably not hig
Date:Thu, 14 Nov 2024 00:30:32 +0100
From:"#!microsuxx"
Message-ID:
| i just dunno the exec cmd to bring back the fd 1 and 2 after usage back to
| tty , or restore from saved
Assuming that this is even slightly relevant to the question here (whether
any of thi
another code is
if u wanna not use . or eval or bash cmd
( . is source )
shopt -s expand_aliases
alias script=" $( < user.bash ) "
script
On Thu, Nov 14, 2024, 1:10 AM #!microsuxx wrote:
> also u need to $log
> may i ask what criteria ur scripts are about
>
> a $log can be
>
> log=/tmp/my.log.
This script:
#!/usr/bin/env bash
# write child script
echo "export XVAR=xx" > child.sh
echo "YVAR=yy" >> child.sh
# source is piped into tee
source child.sh | tee /dev/null
echo "XVAR=$XVAR"
echo "YVAR=$YVAR"
# source is un-piped
source child.sh
echo "XVAR=$XVAR"
echo "YVAR=$YVAR"
prints th
On Wed, Nov 13, 2024 at 15:56:57 -0800, Yuri wrote:
> On 11/13/24 15:44, Greg Wooledge wrote:
> > If the "user script" runs quickly enough, then: source userscript
> > >logfile 2>&1 cat logfile
>
>
> This would fail to save the user script's output in case it would execute
> "exit 1"
Then don't
i agree
its hard to , say , comm clearly together
i suggest for next times more real life true examples
op's msgs werent so much detailed , more bla-neric :))
greets all
On Thu, Nov 14, 2024, 1:35 AM Robert Elz wrote:
> Date:Wed, 13 Nov 2024 15:18:58 -0800
> From:Yuri
Date:Wed, 13 Nov 2024 15:18:58 -0800
From:Yuri
Message-ID:
| I need to (1) source the user script, (2) save this script's output to a
| dedicated file, (3) keep the same output in stdout, and (4) keep
| environment variables that the user script sets for late
also u need to $log
may i ask what criteria ur scripts are about
a $log can be
log=/tmp/my.log.$USER.$SRANDOM
On Thu, Nov 14, 2024, 1:04 AM #!microsuxx wrote:
> maybe ur email formats it wrong
> those are two lines , by greg
> not one
>
> anyway if u append more than one cmd to logfile
> more
maybe ur email formats it wrong
those are two lines , by greg
not one
anyway if u append more than one cmd to logfile
more than one source cmd
u need to use >>logfile instead of >logfile
On Thu, Nov 14, 2024, 1:00 AM #!microsuxx wrote:
>
>
> On Thu, Nov 14, 2024, 12:57 AM Yuri wrote:
>
>> On 1
On Thu, Nov 14, 2024, 12:57 AM Yuri wrote:
> On 11/13/24 15:44, Greg Wooledge wrote:
> > If the "user script" runs quickly enough, then: source userscript
> > >logfile 2>&1 cat logfile
>
>
> This would fail to save the user script's output in case it would
> execute "exit 1"
>
the >logfile makes
On Wed, Nov 13, 2024 at 15:18:58 -0800, Yuri wrote:
> I need to (1) source the user script, (2) save this script's output to a
> dedicated file, (3) keep the same output in stdout, and (4) keep environment
> variables that the user script sets for later commands.
If the "user script" runs quickly
try ..
exec 3> >( tee -a log ) # or 3>>
. user.bash >&3
cmds ; cmds ; vars ; cmds
On Thu, Nov 14, 2024, 12:56 AM #!microsuxx wrote:
> u need to , save out of . script1 to log1 but what was your second
> sentense alike of this first one ?
> u run source over log1 to produce log2 ?
>
> i thought
On 11/13/24 15:44, Greg Wooledge wrote:
If the "user script" runs quickly enough, then: source userscript
>logfile 2>&1 cat logfile
This would fail to save the user script's output in case it would
execute "exit 1"
Yuri
u need to , save out of . script1 to log1 but what was your second sentense
alike of this first one ?
u run source over log1 to produce log2 ?
i thought ur looking for errors and for this set -x and stderr ? no need
for both ?
i need some details clarified ..
On Thu, Nov 14, 2024, 12:48 AM Yuri
Hi !microsuxx,
But I need to save the output of the user script into a dedicated log file.
This script should run, should save its output into a dedicated log, and
then many other commands should use these environment variables.
Their logs can't be combined into one.
Yuri
On 11/13/24 15:
if u dont need stderr even simpler
On Thu, Nov 14, 2024, 12:36 AM #!microsuxx wrote:
> what u need to do with the vars
> include all code in tee
> or try
>
> exec > >( tee -a log ) 2>&1
> set -x
> . my.bash
> ...
>
> what i firstly meant :
>
> #!/bin/bash
> tee -a log < <(
> all code here
> set
what u need to do with the vars
include all code in tee
or try
exec > >( tee -a log ) 2>&1
set -x
. my.bash
...
what i firstly meant :
#!/bin/bash
tee -a log < <(
all code here
set -x ; . code ; other code that needs the vars set
maybe needs a 2> smth
)
try
(
set -x
. mybash
vars_code
) |&
another solution
if u parse output u can intercept and parse without piping
exec 2> >( stderr_parser_cmd ) 1> >( stdout parser cmd )
or both in one
or or
another one :
exec >>log 2>&1
set -x
. cmd
i just dunno the exec cmd to bring back the fd 1 and 2 after usage back to
tty , or restore from
On 11/13/24 14:48, #!microsuxx wrote:
1st source cmd , no extra cmds 2. { . foo ; code ; code ; } | tee 3rd
tee < <( . foo ; cmds )
I need to (1) source the user script, (2) save this script's output to a
dedicated file, (3) keep the same output in stdout, and (4) keep
environment variables
source is not tty dependand , so try ..
tee -a log < <(
exec 2>&1
set -x
. user.bash
)
On Wed, Nov 13, 2024, 11:52 PM Yuri wrote:
> On 11/13/24 14:45, #!microsuxx wrote:
> > depending on actual purpose instead bs demo code , there are serval
> > approaches to code running code
>
>
> The origi
eg in ur puroose u dont need source
and in ur code when u understood | othercmd is in another subshell , u see
it doesnt well
if u pipe to tee , .. well the scope of needed
1st source cmd , no extra cmds
2. { . foo ; code ; code ; } | tee
3rd tee < <( . foo ; cmds )
On Wed, Nov 13, 2024, 11:45 PM
On 11/13/24 14:45, #!microsuxx wrote:
depending on actual purpose instead bs demo code , there are serval
approaches to code running code
The original code in my project runs 'source x.sh > log' where x.sh is
some user-provided script.
I wanted to trace the code using 'set -x' in order to r
depending on actual purpose instead bs demo code , there are serval
approaches to code running code
On Wed, Nov 13, 2024, 11:13 PM Yuri wrote:
> On 11/13/24 14:02, Greg Wooledge wrote:
> > The commands within a pipeline are executed in subshells (child
> > processes), so all variable changes are
On 11/13/24 14:02, Greg Wooledge wrote:
The commands within a pipeline are executed in subshells (child
processes), so all variable changes are discarded when the subshell exits.
This sounds like an implementation detail that should be invisible that
affects how the 'source' feature works.
T
On Wed, Nov 13, 2024 at 13:48:18 -0800, Yuri wrote:
> # source is piped into tee
> source child.sh | tee /dev/null
> echo "XVAR=$XVAR"
> echo "YVAR=$YVAR"
>
> # source is un-piped
> source child.sh
> echo "XVAR=$XVAR"
> echo "YVAR=$YVAR"
> The first 'source' command didn't set variables set or ex
On 11/13/24 4:25 PM, Grisha Levit wrote:
On Wed, Nov 13, 2024 at 3:45 PM Chet Ramey wrote:
On 11/12/24 8:17 PM, Grisha Levit wrote:
I'm not sure if this is the most idiomatic way to write the rule, but
if a libintl.h is generated, it needs to make it into the installed
headers directory to al
On Wed, Nov 13, 2024 at 3:45 PM Chet Ramey wrote:
>
> On 11/12/24 8:17 PM, Grisha Levit wrote:
> > I'm not sure if this is the most idiomatic way to write the rule, but
> > if a libintl.h is generated, it needs to make it into the installed
> > headers directory to allow loadables to build.
>
> I
On 11/12/24 8:17 PM, Grisha Levit wrote:
I'm not sure if this is the most idiomatic way to write the rule, but
if a libintl.h is generated, it needs to make it into the installed
headers directory to allow loadables to build.
I assume you mean third-party loadables, right? None of the examples
On 11/12/24 10:57 PM, Grisha Levit wrote:
If you try using Cflags from the generated pc file, presumably with
something like:
cc $(pkg-config --cflags bash) -c o myload myload.c
the compilation is likely to fail because HAVE_CONFIG_H is not defined.
Thanks for the report.
--
``The lyf s
On 11/12/24 7:18 PM, Grisha Levit wrote:
The latest change,
+Makefile.in
+ - y.tab.h: move from CREATED_HEADERS to INSTALLED_HEADERS so we don't
+ clean it
makes the install-headers target fail for an out-of-tree build since y.tab.h
is in $(BUILD_DIR) but INSTALLED_HEADERS are only looked for
32 matches
Mail list logo
