> [POSIX] doesn't say anything about #! in shell scripts.
Of course not. #! has nothing to do with the shell. It is interpreted by exec.
Doug
On Sun, 31 Oct 2021 10:02:20 +0100
Andreas Kusalananda Kähäri wrote:
> It doesn't say anything about #! in shell scripts and it say nothing
> about the location of the sh shell interpreter or the existance of
> the /bin directory.
"It's very provoking to be called an egg ? very!"
On Sat, Oct 30, 2021 at 12:08:12PM -0400, James K. Lowden wrote:
> On Wed, 27 Oct 2021 20:15:28 +1100
> John Gardner wrote:
>
> > There's already a deprecation warning in-place warning users against
> > relying on the existence of /bin/bash or the assumption that /bin/sh
> > == /bin/bash.
>
> Ev
On Wed, 27 Oct 2021 20:15:28 +1100
John Gardner wrote:
> There's already a deprecation warning in-place warning users against
> relying on the existence of /bin/bash or the assumption that /bin/sh
> == /bin/bash.
Every so often I get a +10 bump on SO for my answer about writing a
portable shell
On Wed, 27 Oct 2021 18:11:36 +1100
"G. Branden Robinson" wrote:
Thanks for the explanation.
> There are multiple competing implementations of all of these except
> Perl (which competes mostly with its own release history).
Heh.
I have occassionally been bitten by mawk/gawk differences. One I
>
> Yes. Mac OS X, at least the version I have access to, uses Bash 3.2 as
> its script interpreter, and zsh 5.8 as its interactive shell.
>
It's more complicated than that. Apple have announced that the default
shell (Bash 3.2) will be removed in a future version of macOS, meaning `
/bin/sh` wi
Hi, James!
I think the sed portability issues in the build are resolved for now,
and pushed.
At 2021-10-26T10:19:23-0400, James K. Lowden wrote:
> I might have a useful platform to try. I am running autoconf 2.69 on a
> NetBSD machine that I hardly ever change. Its sed and make are derived
> from
Hi, Andreas!
At 2021-10-26T23:56:47+0200, Andreas Kusalananda Kähäri wrote:
> If you insert a semicolon or a newline after the b command, you will
> make it more portable. Also, there is no need to repeat the regular
> expression a second time.
>
> /\\##/ { s///; b; }
Thanks for these tip
On Tue, Oct 26, 2021 at 11:56:47PM +0200, Kusalananda Kähäri wrote:
> On Tue, Oct 26, 2021 at 12:47:49PM +0200, Axel Kielhorn wrote:
[cut]
> > Later I get:
> >
> > sed: 1: "1i .lf 1 contrib/sboxes ...": command i expects \ followed by text
>
>
> This is from another GNU sed convinience feature t
On Tue, Oct 26, 2021 at 12:47:49PM +0200, Axel Kielhorn wrote:
> Hello,
>
> I get the following error when building on MacOS 11:
>
> sed: 17: ./contrib/sboxes/notquine.sed: unexpected EOF (pending }’s)
>
> If I remove
>
> /\\##/{
> s/\\##//
> b}
>
> It works:
If you insert a semicolon or
Hi jkl,
> BTW, is this episode yet another nail in the sed coffin?
> Is it another reason not to rely on sed for whatever it is that it's
> doing? I have no dog in the fight, just asking.
No, it's a reason to write portable POSIX sed rather than GNU sed.
Other seds are often packaged on Linux
On Wed, 27 Oct 2021 00:17:49 +1100
"G. Branden Robinson" wrote:
> [1] The system groff is 1.19.2. For someone who's been living on
> groff Git HEAD for four years, it's a severely disorienting
> experience.
Nearly every machine I use required me to build groff from source,
because I like gropdf
Hi, Axel!
I have temporary access to a Mac OS X host[1] so I was able to reproduce
your problems.
At 2021-10-26T12:47:49+0200, Axel Kielhorn wrote:
> Hello,
>
> I get the following error when building on MacOS 11:
>
> sed: 17: ./contrib/sboxes/notquine.sed: unexpected EOF (pending }’s)
>
> If
13 matches
Mail list logo
