On 2024-04-08 05:58, Robert Elz wrote:
Date:Mon, 8 Apr 2024 02:50:29 +0100
From:Kerin Millar
Message-ID:
<20240408025029.e7585f2f52fe510d2a686...@plushkava.net>
| which is to read scripts in their entirety before trying to execute
| the resulting program. To go ab
On Mon, 8 Apr 2024, at 5:29 AM, John Passaro wrote:
> if you wanted this for your script - read all then start semantics, as
> opposed to read-as-you-execute - would it work to rewrite yourself
> inside a function?
>
> function main() { ... } ; main
Mostly, yes. My initial post in this thread sp
On Mon, Apr 8, 2024 at 5:58 AM Robert Elz wrote:
> Shells interpret their input in much the same way, regardless of
> from where it comes. Would you really want your login shell to
> just collect commands that you type (possibly objecting to those
> with syntax errors) but executing none of them
On Mon, Apr 08, 2024 at 12:40:55PM +0700, Robert Elz wrote:
> or perhaps better just:
>
> main() { ... } ; main "$@"
You'd want to add an "exit" as well, to protect against new lines of
code being appended to the script.
On 2024-04-08 14:02, Greg Wooledge wrote:
On Mon, Apr 08, 2024 at 12:40:55PM +0700, Robert Elz wrote:
or perhaps better just:
main() { ... } ; main "$@"
You'd want to add an "exit" as well, to protect against new lines of
code being appended to the script.
Yes that is correct. it's far ea
On Mon, Apr 08, 2024 at 02:23:18PM +0300, ad...@osrc.rip wrote:
> Btw wouldn't it be possible (and worth) temporarily revoking write access to
> the user while it's being executed as root, and restoring original rights
> after execution?
I think that would be a huge overreach. It would also lead
On Apr 08 2024, Greg Wooledge wrote:
> Now imagine what happens if the shell is killed by a SIGKILL, or if
> the system simply crashes during the script's execution. The script
> is left with altered permissions.
Or the script is executed by more than one process at the same time.
--
Andreas S
On 4/7/24 12:17 AM, ad...@osrc.rip wrote:
Hello everyone!
I've attached a minimal script which shows the issue, and my recommended
solution.
Hi. Thanks for the report. This seems more like a case of mistmatched
expectations.
Bash tries, within reason, to read its input a command at a time, a
Date:Mon, 8 Apr 2024 12:32:13 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| The only ash clone that does this is gwsh, all others print "a" and a
| command-not-found error.
I have (today, after your e-mail) changed the NetBSD shell so it works
like is (apparent
On 4/3/24 1:19 PM, Zachary Santer wrote:
On Wed, Apr 3, 2024 at 10:32 AM Chet Ramey wrote:
How long should the shell defer deallocating the coproc after the process
terminates? What should it do to make sure that the variables don't hang
around with invalid file descriptors? Or should the user
On 4/4/24 8:52 AM, Carl Edquist wrote:
Zack illustrated basically the same point with his example:
exec {fd}< <( some command )
while IFS='' read -r line <&"${fd}"; do
# do stuff
done
{fd}<&-
A process-substitution open to the shell like this is effectively a
one-ended
On Mon, Apr 8, 2024 at 5:32 PM Robert Elz wrote:
> The effect is that sharing stdin between the shell script, and other
> commands (than read), is almost certainly never going to work,
Why not? It works fine with other shells
$ cat tst.sh
cat
On 4/4/24 7:23 PM, Martin D Kealey wrote:
I'm somewhat uneasy about having coprocs inaccessible to each other.
I can foresee reasonable cases where I'd want a coproc to utilize one or
more other coprocs.
That's not the intended purpose, so I don't think not fixing a bug to
accommodate some fut
On Mon, 8 Apr 2024 at 01:49, Kerin Millar wrote:
> the method by which vim amends files is similar to that of sed -i.
>
I was about to write "nonsense, vim **never** does that for me", but then I
remembered that using ":w!" instead of ":w" (or ":wq!" instead of ":wq")
will write the file as norm
On Tue, 9 Apr 2024 10:42:58 +1200
Martin D Kealey wrote:
> On Mon, 8 Apr 2024 at 01:49, Kerin Millar wrote:
>
> > the method by which vim amends files is similar to that of sed -i.
> >
>
> I was about to write "nonsense, vim **never** does that for me", but then I
> remembered that using ":w!"
Hmm, looks like I'm partially mistaken.
Vim never does the inode pivot trick *in circumstances where I might've
noticed*, so not when the file:
- has multiple links, or
- is a symlink, or
- is in an unwritable directory, or
- otherwise appears to be something other than a plain file.
But it turns
Date:Mon, 8 Apr 2024 19:35:02 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| Why not? It works fine with other shells
Sure, it is possible to make a useless program like this ...
| $ cat tst.sh
| cat
On Tue, Apr 9, 2024 at 5:17 AM Robert Elz wrote:
> Sure, it is possible to make a useless program like this ...
> Almost all real commands use stdio to read stdin. Playing about
> any more with this absurd example isn't worth the bother. The relevant
> text should simply be deleted from POSIX
On Mon, Apr 8, 2024 at 11:07 AM Chet Ramey wrote:
>
> Bash doesn't close the file descriptor in $fd. Since it's used with `exec',
> it's under the user's control.
>
> The script here explicitly opens and closes the file descriptor, so it
> can read until read returns failure. It doesn't really mat
Configuration Information [Automatically generated, do not change]: Machine:
x86_64 OS:
linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects
-fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -spe
20 matches
Mail list logo
