On 2/24/24 5:40 AM, Koichi Murase wrote:
Meanwhile, the behavior that `exec 50>2.txt' does not have an effect
does not seem to be the intentional design. It seems to be just a
side effect of the manipulation of the saved fds. In this sense, the
strange behavior I observe is the one that Chet d
On 2/24/24 12:11 AM, Koichi Murase wrote:
I have a question. Maybe it's not technically a bug as fd > 9 is
involved, but the resulting behavior appears to be strange. I
received some reports from users in my project and tried to find out
what is happening. This is a reduced case:
#!/usr/bi
2024年2月24日(土) 15:32 Emanuele Torre :
> On Sat, Feb 24, 2024 at 02:11:25PM +0900, Koichi Murase wrote:
> > I have a question. Maybe it's not technically a bug as fd > 9 is
> > involved, but the resulting behavior appears to be strange. I
> > received some reports from users in my project and tried
On Sat, Feb 24, 2024 at 02:11:25PM +0900, Koichi Murase wrote:
> I have a question. Maybe it's not technically a bug as fd > 9 is
> involved, but the resulting behavior appears to be strange. I
> received some reports from users in my project and tried to find out
> what is happening. This is a
On Thu, 26 Jan 2023, 09:37 Sergei Trofimovich, wrote:
> To the bug: looks like 'exec -a' does not work for bash scripts, but does
> work for other executables.
>
Be aware that the kernel is responsible for interpreting #! lines, not bash.
The kernel does several steps when it encounters an exec
On Thu, 26 Jan 2023 00:35:27 -0500
Lawrence Velázquez wrote:
> On Wed, Jan 25, 2023, at 6:37 PM, Sergei Trofimovich wrote:
> > I fear it's a side-effect of the way 'bash' gets executed via shebang by
> > kernel. But maybe not? Somehow direct script execution still manages to
> > preserve script's
On Wed, Jan 25, 2023, at 6:37 PM, Sergei Trofimovich wrote:
> I fear it's a side-effect of the way 'bash' gets executed via shebang by
> kernel. But maybe not? Somehow direct script execution still manages to
> preserve script's name. Is it an intended behaviour that could not be
> easily changed?
root@localhost:~# unset -v z ; cat srcpath ; bash srcpath ; ./srcpath ;
"${z=$PWD/srcpath}" ; bash "$z"
[[ ${z=$BASH_SOURCE} == /* ]] && t=$z || t=$PWD/$z
printf %s\\n "$t"
/root/srcpath
/root/./srcpath
/root/srcpath
/root/srcpath
On Thu, Jan 26, 2023, 12:51 AM Sergei Trofimovich wrote:
> Hello
hi, well, i mean as first example around exec socat, not socats exec
directive ( which i used for script tho )
but i dont remember the circumstances
it was long ago like a phenomen
lines of code appeared instead of files i think
but i cant recall exactly
it just, i removed exec it worked normally
On Sat, Mar 13, 2021 at 01:05:32AM +0100, Alex fxmbsw7 Ratchev wrote:
> i have no example to write here as this was past long
Without sample, i'ts hard to represent your case!
> the story was, i was coding a file server daemon, with socat,
Wow!
> and i figured to use exec why not more exact more
thank you sir
theres a misunderstanding tho
with exec i meant i exec socat instead of without exec
i may be able to reproduce it soon as i need to extend my softwares
peace
On Sun, Mar 14, 2021 at 3:37 PM Dale R. Worley wrote:
> > 2021年3月13日(土) 8:06 Alex fxmbsw7 Ratchev :
> >> but using it res
> 2021年3月13日(土) 8:06 Alex fxmbsw7 Ratchev :
>> but using it resulted sometimes output of code of the script in the output
>> of the files
>> removing exec made it work normally as supposed
One possibility is a typo, using "<<" rather than "<".
Koichi Murase writes:
> I don't know about `socat',
2021年3月13日(土) 8:06 Alex fxmbsw7 Ratchev :
> but using it resulted sometimes output of code of the script in the output
> of the files
> removing exec made it work normally as supposed
I don't know about `socat', but maybe it's just the file descriptor
collision. One needs to make sure that the fil
Thanks for the reply.
I was lost and it seems eval was what I was looking for. Nice time.
On Fri, Sep 28, 2018 at 09:11:26AM +0300, Francis Gathea wrote:
> Same thing in a shell script.
>
> On 28/09/2018, Francis Gathea wrote:
> > Hi. Why is this function closing out my session if typed on the terminal?
> >
First, please do not "top-quote". When you resond, put your response
UNDER t
Same thing in a shell script.
On 28/09/2018, Francis Gathea wrote:
> Hi. Why is this function closing out my session if typed on the terminal?
>
> On Aug 19, 2018, at 8:45 PM, Lars Schneider wrote:
>
>
>> On Aug 19, 2018, at 6:33 PM, Lars Schneider wrote:
>>
>> Hi,
>>
>> consider this script:
>>
>> #!/bin/bash
>> [ "`whoami`" = "root" ] || {
>>exec sudo -u root "$0" "$@"
>> }
>> read -s -p "enter stuff:
> On Aug 19, 2018, at 6:33 PM, Lars Schneider wrote:
>
> Hi,
>
> consider this script:
>
> #!/bin/bash
> [ "`whoami`" = "root" ] || {
> exec sudo -u root "$0" "$@"
> }
> read -s -p "enter stuff: " stuff
>
> If I run the script as normal user (not root!) and I
On 7/28/15 5:48 AM, Andreas Schwab wrote:
> Running exec in an interactive shell does not restore the terminal
> signals TSTP, TTIN, TTOU, causing them to be ignored in the new command.
>
> $ trap
> $ exec bash
> $ trap
> trap -- '' SIGTSTP
> trap -- '' SIGTTIN
> trap -- '' SIGTTOU
Thanks for the
2015-07-28 11:48:54 +0200, Andreas Schwab:
> Running exec in an interactive shell does not restore the terminal
> signals TSTP, TTIN, TTOU, causing them to be ignored in the new command.
>
> $ trap
> $ exec bash
> $ trap
> trap -- '' SIGTSTP
> trap -- '' SIGTTIN
> trap -- '' SIGTTOU
>
> Andreas.
On Wed, Sep 21, 2011 at 01:09:32PM -0400, Pete Nelson wrote:
> I'm confused about what exec is doing in this case.
>
> Sample script t:
>
> #!/bin/bash
> echo $0 pid: $$ ppid: $PPID args: $* 1>&2
> if [ -z "$1" ]; then
> exec $0 first | $0 second
> echo should not reach here
> fi
It does not
Pete Nelson writes:
> I'm confused about what exec is doing in this case.
>
> Sample script t:
>
> #!/bin/bash
> echo $0 pid: $$ ppid: $PPID args: $* 1>&2
> if [ -z "$1" ]; then
> exec $0 first | $0 second
> echo should not reach here
> fi
>
> output:
>
> $ ./t
> ./t pid: 13746 ppid: 12823 ar
Correct, my idea was to redirect the output of the whole script. The
example used a sample 'echo' but it could instead produce dynamically
some ISO-8859 encoded strings, due to some external constraints (ie.
database). I thought it could be an easy way to do that in a single
script. And your la
Bob Proulx writes:
> Beyond this I am not sure what you wanted to do with exec. You may
> have wanted this:
>
> exec iconv -f ISO_8859-1 -t UTF-8
I think he rather wants this:
exec > >(iconv -f ISO_8859-1 -t UTF-8)
(See Process Substitution in the bash manual.)
Alternatively, enclose the w
fpo wrote:
> Well, I am not sure it is a bug. I just tried this after reading the
> manual page and the exec built-in command. I was expecting to have the
> iconv command be called on the standard output of the shell script.
Thank you for the report. But this is not a bug. You are
misunderst
On 1/25/10 8:32 AM, mike bakhterev wrote:
> Bash Version: 4.0
> Patch Level: 35
> Release Status: release
>
> Description:
> Something is wrong with variable substitution in the exec invocation.
> When i try to close file descriptor whose number is in variable X with
> command:
mike bakhterev a écrit :
>
> Description:
> Something is wrong with variable substitution in the exec invocation.
> When i try to close file descriptor whose number is in variable X with
> command:
>
> exec $X>&-
I think the operator is 2> as a whole; you cann
27 matches
Mail list logo
