> [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
On Friday, 29 October 2021 21:24:45 BST T. Kurt Bond wrote:
> > The pdf I sent to the list yesterday [
>
> https://lists.gnu.org/archive/html/groff/2021-10/msg00094.html ] Is
> produced entirely by groff and has a full clickable index.
>
> Wonderful! Someone *was* suitably inspired to implement
> The pdf I sent to the list yesterday [
https://lists.gnu.org/archive/html/groff/2021-10/msg00094.html ] Is
produced entirely by groff and has a full clickable index.
Wonderful! Someone *was* suitably inspired to implement multiple indexes!
Would it be possible to get references to the start of
On Friday, 29 October 2021 19:38:42 BST T. Kurt Bond wrote:
> [I hit "reply" on my previous attempt at this email, so it went only to
> Ralph. Sorry about that. At least this version has the correct CSTR #.]
> I'm an emacs user, and I use the info version of the groff texinfo manual,
> as well as
[I hit "reply" on my previous attempt at this email, so it went only to
Ralph. Sorry about that. At least this version has the correct CSTR #.]
I'm an emacs user, and I use the info version of the groff texinfo manual,
as well as the manual pages, and usually go to the trouble of getting the
PDF
Hi John,
> I was thinking of ms(7) more than manual pages, actually.
> Think single-page HTML output.
Based on the transcription this list did of Tim O'Reilly's ‘Unix Text
Processing’ — now only available second hand, https://amzn.to/3bkamGb —
perhaps an shared effort to switch would work for the
Hi John,
> In lieu of escaped newlines and awkward sed(1) formatting, you can use
> the following line to insert an empty line:
>
> /^Before$/ { N; s/\n/&&/; }
With the caveat that the line read by N won't be processed as it would
have been otherwise. These two show the difference which might no
On Fri, Oct 29, 2021 at 05:19:00AM +1100, John Gardner wrote:
> I was thinking of ms(7) more than manual pages, actually. Think single-page
> HTML output.
-ms lends itself to parsing nicely. I wrote something called webroff
(in perl) that took ms input and spit out a website. In the early
days o
>
> https://mandoc.bsd.lv/texi2mdoc/
I was thinking of ms(7) more than manual pages, actually. Think single-page
HTML output.
mdoc(7) is too restrictive and specialised to lend itself well to the
various applications Texinfo manuals are used for.
(Anyway, I was just spitballing. I want an excus
In lieu of escaped newlines and awkward sed(1) formatting, you can use the
following line to insert an empty line:
/^Before$/ { N; s/\n/&&/; }
Note that BSD sed(1) is picky about braces and semicolons.
I have groff building successfully on Mac OS X now.
>
I recently upgraded to macOS 12.0.1 (M
>
> 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-27T00:07:22+0200, Andreas Kusalananda Kähäri wrote:
> Actually, that only makes it work with OpenBSD sed and GNU sed. It
> still fails with
>
> sed: Unrecognized command: .lf 1 doc/webpage.ms
>
> when using Plan 9 sed. Not tested with macOS.
>
> So it looks like
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
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:
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-am
GEN contrib/sboxes/msboxes.ms
GROFFcontr
24 matches
Mail list logo
