the alias bug(s) i experience again in simple code
i would use the dev tree but as you may saw on my other mail it doesnt run
please include the alias fix in mainstream releases or take the title of
keeping aliases to high part nowork
for some reason it pasted it with wrong newlines, ill try fixin
On 10/11/21 07:09, Robert Elz wrote:
> This is clearly an OS problem, not one in bash.
>
> POSIX says of ENOENT as it applies to the exec*() set of functions:
>
> [ENOENT] A component of path or file does not name an existing file
> or path or file is an empty string.
>
> "path" and "file
the mv a old new looks like it can be achieved by cgroups freeze [i only
have hears so] and ye its not portable
if choosen to somehow freeze it, i dunno, transparently somehow, for
letting changes happen
btw on my secondlast bash.git.devel build it ended up with some binary that
also produced via
Date:Mon, 11 Oct 2021 11:00:54 -0400
From:Chet Ramey
Message-ID: <45ecd950-9e9b-553b-132b-04d1dcfad...@case.edu>
| When execve returns this error for what is a clearly invalid reason,
The problem is that sometimes it will probably be an invalid reason
(that's where
On 10/5/21 4:41 AM, Koichi Murase wrote:
> I have questions on the new feature ${var/pat/&} in the devel branch.
>
>> commit f188aa6a013e89d421e39354086eed513652b492 (upstream/devel)
>> Author: Chet Ramey
>> Date: Mon Oct 4 15:30:21 2021 -0400
>>
>> enable support for using `&' in the patte
as the topic says
i fetched it earlier today, compiled, and tho it rather segfaults
due to i dunno to debug this, this mail consists of 3 parts, 1 gdb + bt
./bash (loading in bashrc a script which makesnit segfault)
and once with gdb ./bash -vx
third part is the code
forth part is around where in
On 10/11/21 7:09 AM, Robert Elz wrote:
> Date:Sun, 10 Oct 2021 21:09:53 -0400
> From:Eli Schwartz
> Message-ID: <4a362385-066d-0795-9a02-ff8bbb920...@archlinux.org>
>
> | So I wonder, if bash already in this exact case attempts to open() the
> | file and read() it
On Mon, Oct 11, 2021 at 03:28:18PM +0900, Hyunho Cho wrote:
> If i want to know whether there are input available from stdin
> then i use "read -t 0" command like this
>
> if read -t 0; then# first check input available
> while read line; do ... done
> ...
> fi
What are you actually trying to
yea if date didnt have time to do, in one sync case it did, sleep 0.001
wasnt enuff, i didnt test much more
sorry, thanks
On Mon, Oct 11, 2021, 13:37 Robert Elz wrote:
> Date:Mon, 11 Oct 2021 10:26:12 +0200
> From:Alex fxmbsw7 Ratchev
> Message-ID: <
> caalkerhta-kb
Date:Mon, 11 Oct 2021 10:26:12 +0200
From:Alex fxmbsw7 Ratchev
Message-ID:
| i still have hopes it syncs, arent pipes file fifos or something
it makes no difference, you cannot sync something
which has not yet been written, and in the
examples it us very likely
Date:Sun, 10 Oct 2021 21:09:53 -0400
From:Eli Schwartz
Message-ID: <4a362385-066d-0795-9a02-ff8bbb920...@archlinux.org>
| So I wonder, if bash already in this exact case attempts to open() the
| file and read() it to look for a shebang, what's the harm in assuming
a sleep .001 was by far no enuff
i still have hopes it syncs, arent pipes file fifos or something
i understand it can also be not doing anything but timings there yes
On Mon, Oct 11, 2021, 10:17 Andreas Schwab wrote:
> On Okt 11 2021, Alex fxmbsw7 Ratchev wrote:
>
> > a sync in hope it syncs pip
On Okt 11 2021, Alex fxmbsw7 Ratchev wrote:
> a sync in hope it syncs pipes
It doesn't. It just alters the timing.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
a sync in hope it syncs pipes makes the date | f work, but not for <( date )
f() { sync; read -t 0 ; printf $?\\n ; } ; date | f ; f <( date ) ; read -t
0 <( date ) ; printf $?\\n
0
1
1
On Mon, Oct 11, 2021, 09:42 Andreas Schwab wrote:
> On Okt 11 2021, Hyunho Cho wrote:
>
> > this command wor
On Okt 11 2021, Hyunho Cho wrote:
> this command works well in *shell script file*
> but in shell function does not work well
This has nothing to do with shell functions. It is a simple race
condition.
> sh$ echo 111 | myfunc# OK
> yes
>
> sh$ cat foo.c | myfunc# NOT WORK!
>
> s
15 matches
Mail list logo