From Newsgroup: comp.unix.shell

Greetings,
Hope someone is having an okay Summer; I'm ready for Fall.

PDKsh question:

Ref: PD KSH v5.2.14 99/7/13.2 (default Ksh on NetBSD 11.0)

I'm wondering if there is a way -- in pdksh -- to accomplish
backslash expansion, i.e. '\r', in patterns used for parameter
substitution? Specifically I'd like to natively strip off
the trailing carriage return from 'read -r REPLY'.

What appears to work:

$ REPLY=fubar^M
$ REPLY="${REPLY%$(print '\r')}"
print $REPLY |cat -v
fubar

Entering a literal ^M after the "%" also works.

What doesn't work (but I'd like it to):

$ REPLY=fubar^M
$ REPLY="${REPLY%$'\r'}"
print $REPLY |cat -v
fubar^M

The above works in Bash and MirKsh, likely Ksh93 too so I was
somewhat surprised it failed with PDKsh. Tried numerous ways
to quote '\r' but none worked so I'm inclined to believe that
backslash expansion is not a thing for substitution patterns
in PDKsh -- am I wrong ?

-tdc
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-08-11 21:39, Top Dead Ctr wrote:

Greetings,
Hope someone is having an okay Summer; I'm ready for Fall.

PDKsh question:

Disclaimer: I haven't touched PDksh for decades!
(Maybe you find some useful hints below anyway.)

Ref: PD KSH v5.2.14 99/7/13.2-a (default Ksh on NetBSD 11.0)

I'm wondering if there is a way -- in pdksh -- to accomplish
backslash expansion, i.e. '\r', in patterns used for parameter substitution?-a Specifically I'd like to natively strip off
the trailing carriage return from 'read -r REPLY'.

Note that 'REPLY' is the standard target for read (no need to
specify it, REPLY can be omitted) - it's sensible to use your
own variable names. (Just BTW.)

What appears to work:

$ REPLY=fubar^M
$ REPLY="${REPLY%$(print '\r')}"
print $REPLY |cat -v
fubar

Entering a literal ^M after the "%" also works.

What doesn't work (but I'd like it to):

$ REPLY=fubar^M
$ REPLY="${REPLY%$'\r'}"

Yes, "ANSI Strings" like $'\r' is what I'd have suggested with
other shells (ksh, bash, zsh)!

If PDksh does not support it... - what do you expect now?

You could fix your data and pass your data through a 'tr -d'
pipeline.

Or if your interface is the 'read' command you may set IFS=^M
to redefined the separator for the respective read command

IFS=^M read -r

Or, portably, use a variable to store the ^M using 'printf'

cr=$( printf "\r" )

then use "${cr}" where you need it; e.g. REPLY=${REPLY%${cr}}

print $REPLY |cat -v
fubar^M

The above works in Bash and MirKsh, likely Ksh93 too so I was
somewhat surprised it failed with PDKsh.

Historically PDksh was a comparably lousy shell; and I wouldn't
touch it. (I don't know whether it got better lately.) Usually
Bash was faster adopting such features from original Ksh of else.

Tried numerous ways
to quote '\r' but none worked so I'm inclined to believe that
backslash expansion is not a thing for substitution patterns
in PDKsh -- am I wrong ?

Sorry I cannot suggest PDksh specifics; inspect its man page.

(If you can replace PDksh I strongly suggest to do so.)

Janis

-tdc

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-08-11, Top Dead Ctr <tdc@invalid.invalid> wrote:

Specifically I'd like to natively strip off
the trailing carriage return from 'read -r REPLY'.

Side note: That's weird because there shouldn't be a trailing
carriage return in the first place.

What doesn't work (but I'd like it to):

$ REPLY=fubar^M
$ REPLY="${REPLY%$'\r'}"

The above works in Bash and MirKsh, likely Ksh93 too so I was
somewhat surprised it failed with PDKsh.

pdksh pre-dates the $'...' syntax. Unless that has been added to
NetBSD's version, the shell simply doesn't support it.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-08-12 00:17, Christian Weisgerber wrote:

On 2026-08-11, Top Dead Ctr <tdc@invalid.invalid> wrote:

Specifically I'd like to natively strip off
the trailing carriage return from 'read -r REPLY'.

Side note: That's weird because there shouldn't be a trailing
carriage return in the first place.

You certainly meant a trailing _newline_.

$ printf "Hello world\r\n" | read x; printf "$x" | od -c
0000000 H e l l o w o r l d \r

Carriage returns are *not* removed by 'read'. (The same
[standard] behavior with bash, dash, etc.)

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Top Dead Ctr <tdc@invalid.invalid> writes:
[...]

PDKsh question:

Ref: PD KSH v5.2.14 99/7/13.2 (default Ksh on NetBSD 11.0)

I'm wondering if there is a way -- in pdksh -- to accomplish
backslash expansion, i.e. '\r', in patterns used for parameter
substitution? Specifically I'd like to natively strip off
the trailing carriage return from 'read -r REPLY'.

What appears to work:

$ REPLY=fubar^M
$ REPLY="${REPLY%$(print '\r')}"
print $REPLY |cat -v
fubar

Entering a literal ^M after the "%" also works.

What doesn't work (but I'd like it to):

$ REPLY=fubar^M
$ REPLY="${REPLY%$'\r'}"
print $REPLY |cat -v
fubar^M

The above works in Bash and MirKsh, likely Ksh93 too so I was
somewhat surprised it failed with PDKsh. Tried numerous ways
to quote '\r' but none worked so I'm inclined to believe that
backslash expansion is not a thing for substitution patterns
in PDKsh -- am I wrong ?

Why do you care about '\r' characters? In normal usage, you
shouldn't see '\r' characters unless you add them explicitly, as
you have your sample code above. Are you reading Windows text files?

If you're copying files from Windows to NetBSD or another Unix-like
system, consider translating the files as you copy them. If you're
doing something else, tell us what underlying problem you're trying
to solve, and we might be able to suggest a better solution.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-08-12 01:28, Keith Thompson wrote:

Top Dead Ctr <tdc@invalid.invalid> writes:
[...]

I'm wondering if there is a way -- in pdksh -- to accomplish
backslash expansion, i.e. '\r', in patterns used for parameter
substitution? Specifically I'd like to natively strip off
the trailing carriage return from 'read -r REPLY'.
[...]

Why do you care about '\r' characters? In normal usage, you
shouldn't see '\r' characters unless you add them explicitly, as
you have your sample code above. Are you reading Windows text files?

Mind that there is no such beast as "normal usage" in our domain.
IETF Internet protocols' data may contain '\r'. Web-pages/content
may contain '\r'. Yes, and DOS/Windows sources, or old (pre-OS X)
Apple data.


Sometimes you are even surprised by unexpected and dis-functional
behavior:

$ cat cr
ls *
$ sh cr
ls: cannot access '*'$'\r': No such file or directory

one might expect a shell to behave more tolerant to line endings
but, OTOH, ^M ('\r', CR) is primarily just "data".

Janis

[...]

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-08-12 01:28, Keith Thompson wrote:

Top Dead Ctr <tdc@invalid.invalid> writes:
[...]

I'm wondering if there is a way -- in pdksh -- to accomplish
backslash expansion, i.e. '\r', in patterns used for parameter
substitution? Specifically I'd like to natively strip off
the trailing carriage return from 'read -r REPLY'.
[...]

Why do you care about '\r' characters? In normal usage, you
shouldn't see '\r' characters unless you add them explicitly, as
you have your sample code above. Are you reading Windows text files?

Mind that there is no such beast as "normal usage" in our domain.
IETF Internet protocols' data may contain '\r'. Web-pages/content
may contain '\r'. Yes, and DOS/Windows sources, or old (pre-OS X)
Apple data.

Sometimes you are even surprised by unexpected and dis-functional
behavior:

$ cat cr
ls *
$ sh cr
ls: cannot access '*'$'\r': No such file or directory

I've seen even worse behavior, with shells that seem to treat
'\r' as if were a printable character. (sh is dash on my system.)

$ cat d
date
$ sh d
: not found
$ cat -A d
date^M$
$ sh d 2>&1 | cat -A
d: 1: date^M: not found$
$

one might expect a shell to behave more tolerant to line endings
but, OTOH, ^M ('\r', CR) is primarily just "data".

Fair enough.

Yes, most Unix shells treat '\r' as just another character,
and pay no attention to the convention of using it as part of an
end-of-line marker. (Many other tools, including a number of text
editors, recognize "\r\n" as a line ending and try to handle it
more or less gracefully.)

My question "Why do you care about '\r' characters?" could easily be interpreted to imply that you *shouldn't* care about '\r' characters,
but that's not how I meant it. Knowing *why* the OP is seeing '\r'
characters is likely to help in coming up with a better solution
to the underlying issue.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 8/11/26 4:17 PM, Christian Weisgerber wrote:

On 2026-08-11, Top Dead Ctr <tdc@invalid.invalid> wrote:

Specifically I'd like to natively strip off
the trailing carriage return from 'read -r REPLY'.

Side note: That's weird because there shouldn't be a trailing
carriage return in the first place.

It's being used similar to a CGI script and the carriage returns
get automatically appended.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 8/11/26 3:01 PM, Janis Papanagnou wrote:

On 2026-08-11 21:39, Top Dead Ctr wrote:

Greetings,
Hope someone is having an okay Summer; I'm ready for Fall.

PDKsh question:

Disclaimer: I haven't touched PDksh for decades!
(Maybe you find some useful hints below anyway.)

Ref: PD KSH v5.2.14 99/7/13.2-a (default Ksh on NetBSD 11.0)

I'm wondering if there is a way -- in pdksh -- to accomplish
backslash expansion, i.e. '\r', in patterns used for parameter
substitution?-a Specifically I'd like to natively strip off
the trailing carriage return from 'read -r REPLY'.

Note that 'REPLY' is the standard target for read (no need to
specify it, REPLY can be omitted) - it's sensible to use your
own variable names. (Just BTW.)

Yes I just explicitly used it so it was clearer where REPLY
came from in the examples.

What appears to work:

$ REPLY=fubar^M
$ REPLY="${REPLY%$(print '\r')}"
print $REPLY |cat -v
fubar

Entering a literal ^M after the "%" also works.

What doesn't work (but I'd like it to):

$ REPLY=fubar^M
$ REPLY="${REPLY%$'\r'}"

Yes, "ANSI Strings" like $'\r' is what I'd have suggested with
other shells (ksh, bash, zsh)!

If PDksh does not support it... - what do you expect now?

You could fix your data and pass your data through a 'tr -d'
pipeline.

Or if your interface is the 'read' command you may set IFS=^M
to redefined the separator for the respective read command

-a IFS=^M read -r

I sort of like this approach of eliminating ^M at the source.
In some test scripts I had to do 'set -o noglob' but that might
not be needed in-line.

Or, portably, use a variable to store the ^M using 'printf'

-a cr=$( printf "\r" )

then use "${cr}" where you need it; e.g. REPLY=${REPLY%${cr}}

This does work but as there is generally just the one trailing ^M
it seems to me I might as well use $(print '\r') and skip creating
the CR variable. I would definitely use a read-only var if it got
used multiple times. Regarding filter piping through tr, cut, sed,
etc., if I start seeing embedded ^M or other control characters
I'll likely need to use that approach.

Historically PDksh was a comparably lousy shell; and I wouldn't
touch it. (I don't know whether it got better lately.)-a Usually
Bash was faster adopting such features from original Ksh of else.

Tried numerous ways
to quote '\r' but none worked so I'm inclined to believe that
backslash expansion is not a thing for substitution patterns
in PDKsh -- am I wrong ?

Sorry I cannot suggest PDksh specifics; inspect its man page.

(If you can replace PDksh-a I strongly suggest to do so.)

I agree, it's lacking and NetBSD should consider including a
better shell as part of their distribution. In my usage case
I'm trying to stick with just the tools provided in the base
install and pdksh is arguably the best of the 3 (ash and csh
being the other 2).

Thanks to everyone who provided feedback!

-tdc
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-08-12 16:59, Top Dead Ctr wrote:

On 8/11/26 3:01 PM, Janis Papanagnou wrote:

[...]
-a-a IFS=^M read -r

I sort of like this approach of eliminating ^M at the source.

At the _source_, yes. - But (personally) I don't like fiddle with
IFS in the 'read' here, and I usually also avoid a literal Ctrl-M.
(YMMV.) - I just mentioned that variant for sort of completeness!

[...]

Or, portably, use a variable to store the ^M using 'printf'

-a-a cr=$( printf "\r" )

then use "${cr}" where you need it; e.g. REPLY=${REPLY%${cr}}

This does work but as there is generally just the one trailing ^M
it seems to me I might as well use $(print '\r') and skip creating
the CR variable.

Probably a matter of opinion. I think it's good to have constants
defined once (at top) then use them in a better legible way where
it's needed. Also I wouldn't want a subshell-context be opened and
printf called anew with every command expansion. (Think about it.)

Note also that your 'print' is non-standard; I deliberately used
'printf' as a standard and thus better portable command. (You just
pay storage for an additional byte 'f'.) - The only context where
I'm usually still using ksh's 'print' is when I need to adjust the
file descriptor; I like its '-u' option.

I would definitely use a read-only var if it got
used multiple times.

As said, it's more than just a textual position in the source;
it's also the repeated call overhead to calculate the '\r' value,
and the increased legibility of the expression where you use it.

Regarding filter piping through tr, cut, sed,
etc.,-a if I start seeing embedded ^M or other control characters
I'll likely need to use that approach.

[...]

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-08-11, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Specifically I'd like to natively strip off
the trailing carriage return from 'read -r REPLY'.

Side note: That's weird because there shouldn't be a trailing
carriage return in the first place.

You certainly meant a trailing _newline_.

No, I meant a carriage return. Where does it come from? The
original phrasing "the trailing carriage return" makes it sound as
if this was perfectly expected. It isn't.

$ printf "Hello world\r\n" | read x; printf "$x" | od -c

And you have to go out of your way to insert one here.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-08-12 17:28, Christian Weisgerber wrote:

On 2026-08-11, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Specifically I'd like to natively strip off
the trailing carriage return from 'read -r REPLY'.

Side note: That's weird because there shouldn't be a trailing
carriage return in the first place.

You certainly meant a trailing _newline_.

No, I meant a carriage return. Where does it come from? The
original phrasing "the trailing carriage return" makes it sound as
if this was perfectly expected. It isn't.

You previous post sounded like you assumed that CR would be
removed by 'read'. - This has been demonstrated by the code
quoted below to not be true.

The CRs are actually _expected_ in the OPs data, as explained
already by him (in his application case) and by me (generally).

His data has CRs, and using default 'read' will not remove it;
whether it's part of a very common CR/LF or just alone as CR.

So it's not clear what you had considered to be "weird" when
you wrote: "there shouldn't be a trailing carriage return in
the first place."

Janis

$ printf "Hello world\r\n" | read x; printf "$x" | od -c

And you have to go out of your way to insert one here.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 12/08/2026 10:59 PM, Top Dead Ctr wrote:

I agree, it's lacking and NetBSD should consider including a
better shell as part of their distribution.-a In my usage case
I'm trying to stick with just the tools provided in the base
install and pdksh is arguably the best of the 3 (ash and csh
being the other 2).

Then shouldn't the /proper solution/ be to just fix the pdksh in
NetBSD? I admit curiousity about this operating system, so I'm
probably also going to use pdksh for a bit; at least until I'd in-
stall zsh and/or tcsh which are my two favorite interactive shells.

And if you want me to look into updating pdksh for this purpose, can
you please re-summarize the problem in terms of a bug report and/or
a feature request for pdksh? While I may look into fixing pdksh, I'm
not in the mood to go through all the discussion and try to divine what
the actual problem is about in the first place.


Best wishes, and happy kshing!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 8/12/26 9:45 PM, Johann 'Myrkraverk' Oskarsson wrote:

On 12/08/2026 10:59 PM, Top Dead Ctr wrote:

I agree, it's lacking and NetBSD should consider including a
better shell as part of their distribution.-a In my usage case
I'm trying to stick with just the tools provided in the base
install and pdksh is arguably the best of the 3 (ash and csh
being the other 2).

Then shouldn't the /proper solution/ be to just fix the pdksh in
NetBSD?-a I admit curiousity about this operating system, so I'm
probably also going to use pdksh for a bit; at least until I'd in-
stall zsh and/or tcsh which are my two favorite interactive shells.

And if you want me to look into updating pdksh for this purpose, can
you please re-summarize the problem in terms of a bug report and/or
a feature request for pdksh?-a While I may look into fixing pdksh, I'm
not in the mood to go through all the discussion and try to divine what
the actual problem is about in the first place.

Best wishes, and happy kshing!

That's a generous offer. I'm not really sure how open the NetBSD
developers would be to extending the version of pdksh distributed
in the base system. They DO ship an extended version of The One
True AWK, adding gensub() and some time functions from Gawk. You
could inquiry on one of the various mlists (you don't need to be
subscribed to post); https://netbsd.org/mailinglists/ . Probably
posting to "netbsd-users" is a good starting point.

The NetBSD pkgsrc system (not NetBSD-specific but primarily used
with NetBSD) has a packaged version of pdksh so simply submitting
a patch might be the best way of offering pdksh extensions which
the developers can scrutinize and hopefully fold into the base
distribution. FYI: currently LLM-generated code policy is that
it's not allowed.

I've packaged up a few pkgsrc packages over the years so if you
really want to take this on I'm willing to do that task. pkgsrc
in the past was strictly available by CVS but Git and I think Hg
is also an option; the pkgsrc pdksh package is here:

https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/shells/pdksh/index.html

There are no patches currently applied to the 23 year old source
tarball so yours could be the first!

As to the _what_ of said extensions, I think it's essentially
adding the following to the parameter expansion feature set:

1) backslash expansion, ie. '\r' => ^M
2) //[%#]<pat>/<repl>/ style substitutions

I've no idea how hard this would and I'm actually fine with just
making use of the current features in pdksh as I'm a hobbyist and
actually kind of enjoy finding work-arounds for old software.

Cheers,
-tdc
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 14/08/2026 2:20 AM, Top Dead Ctr wrote:

On 8/12/26 9:45 PM, Johann 'Myrkraverk' Oskarsson wrote:

On 12/08/2026 10:59 PM, Top Dead Ctr wrote:

I agree, it's lacking and NetBSD should consider including a
better shell as part of their distribution.-a In my usage case
I'm trying to stick with just the tools provided in the base
install and pdksh is arguably the best of the 3 (ash and csh
being the other 2).

Then shouldn't the /proper solution/ be to just fix the pdksh in
NetBSD?-a I admit curiousity about this operating system, so I'm
probably also going to use pdksh for a bit; at least until I'd in-
stall zsh and/or tcsh which are my two favorite interactive shells.

And if you want me to look into updating pdksh for this purpose, can
you please re-summarize the problem in terms of a bug report and/or
a feature request for pdksh?-a While I may look into fixing pdksh, I'm
not in the mood to go through all the discussion and try to divine what
the actual problem is about in the first place.


Best wishes, and happy kshing!

That's a generous offer.-a I'm not really sure how open the NetBSD
developers would be to extending the version of pdksh distributed
in the base system.-a They DO ship an extended version of The One
True AWK, adding gensub() and some time functions from Gawk. You
could inquiry on one of the various mlists (you don't need to be
subscribed to post); https://netbsd.org/mailinglists/ .-a Probably
posting to "netbsd-users" is a good starting point.

Dear Top Dead,

I'm going to take this slowly, and install NetBSD in a VM, then take
a look at the various mailing lists, and the code.

The NetBSD pkgsrc system (not NetBSD-specific but primarily used
with NetBSD) has a packaged version of pdksh so simply submitting
a patch might be the best way of offering pdksh extensions which
the developers can scrutinize and hopefully fold into the base distribution.-a FYI: currently LLM-generated code policy is that
it's not allowed.

No worries, I never code with L.L.Ms. And for the record, you can
find my name in both FreeBSD and Illumos sources in the /sed/ prog-
ram. It's the same change. I'm familiar with upstreaming changes
like this, but I haven't done it for over a decade I believe. I
think my last change was to tune -- so to speak -- the TCP/IP of the
FreeBSD kernel. Done under a different pseudonym, you won't find
my real name in the FreeBSD kernel sources.

If you're curious, I might try to find that change, and see if it's
still there and not reverted.

I've packaged up a few pkgsrc packages over the years so if you
really want to take this on I'm willing to do that task.-a pkgsrc
in the past was strictly available by CVS but Git and I think Hg
is also an option; the pkgsrc pdksh package is here:

https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/shells/pdksh/index.html

I can work with all three, I don't care what the upstream developers
use. Thanks for the direct link to pdksh.

There are no patches currently applied to the 23 year old source
tarball so yours could be the first!

As to the _what_ of said extensions, I think it's essentially
adding the following to the parameter expansion feature set:

-a1) backslash expansion, ie. '\r' => ^M
-a2) //[%#]<pat>/<repl>/ style substitutions

I've no idea how hard this would and I'm actually fine with just
making use of the current features in pdksh as I'm a hobbyist and
actually kind of enjoy finding work-arounds for old software.

Neither do I. 1) should be trivial, as text processing \x -> ^x for
some value of x is quite easy. 2) I'm not so sure about, because it
depends on the complexity of <pat>, or what people expect to be avail-
able, and what the pdksh sources already have of such functions. I've
not yet coded my own string pattern recognition, but string recognition
without wildcards is covered in Mailund's book, and I might have a
chance to use that, if there's nothing in the pdksh sources already.

Then of course, the NetBSD developers might have an opinion about what
patterns to accept, and where to get the relevant functions, so let's
just wing it.

My next task is then to install NetBSD in a VM. I expect I'll do that
coming Monday. The reason I can do all this is because I'm currently
between jobs, and this will be a nice warmup before I start the next
dayjob. Also, I'm curious if I can do this, and if the NetBSD develop-
ers will accept my changes.


So assuming no hickups, I'll check in on Monday after booting up NetBSD.
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Thu, 13 Aug 2026 12:20:03 -0600, Top Dead Ctr wrote:

I'm not really sure how open the NetBSD developers would be to
extending the version of pdksh distributed in the base system.

Is this different from the other BSDs? Is there no common upstream
that they all draw from?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-08-13, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

I'm not really sure how open the NetBSD developers would be to
extending the version of pdksh distributed in the base system.

Is this different from the other BSDs? Is there no common upstream
that they all draw from?

The last common upstream was 4.4BSD Lite in 1994 or so.
(Yes, that simplifies a much messier history.)

That came with a version of the Almquist shell. FreeBSD has reworked
that shell extensively since then. OpenBSD replaced it with pdksh
in 1996, which IIRC offered better Bourne/POSIX conformance at the
time.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Fri, 14 Aug 2026 17:18:08 -0000 (UTC), Christian Weisgerber wrote:

On 2026-08-13, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

I'm not really sure how open the NetBSD developers would be to
extending the version of pdksh distributed in the base system.

Is this different from the other BSDs? Is there no common upstream
that they all draw from?

The last common upstream was 4.4BSD Lite in 1994 or so. (Yes, that
simplifies a much messier history.)

That came with a version of the Almquist shell. FreeBSD has reworked
that shell extensively since then. OpenBSD replaced it with pdksh in
1996, which IIRC offered better Bourne/POSIX conformance at the
time.

I had a look to see what was available on Debian, and found this <https://packages.debian.org/trixie/mksh>:

mksh is the successor of the Public Domain Korn shell (pdksh), a
Bourne/POSIX compatible shell which is largely similar to the
original AT&T Korn Shell (ksh88/ksh93). It includes bug fixes and
feature improvements, in order to produce a modern, robust shell
good for interactive and especially script use. mksh has UTF-8
support (in string operations and the Emacs editing mode). The
code has been cleaned up and simplified, bugs fixed, standards
compliance added, and several enhancements (for extended
compatibility to other modern shells, as well as a couple of its
own) are available. This shell is Debian Policy 10.4 compliant and
works as /bin/sh on Debian systems (use the /bin/lksh executable)
and is a good rescue and initrd shell (consider the
/bin/mksh-static executable).

Perhaps a better basis for ongoing use than old pdksh code?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 8/14/26 3:05 PM, Lawrence DrCOOliveiro wrote:

On Fri, 14 Aug 2026 17:18:08 -0000 (UTC), Christian Weisgerber wrote:

On 2026-08-13, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

I'm not really sure how open the NetBSD developers would be to
extending the version of pdksh distributed in the base system.

Is this different from the other BSDs? Is there no common upstream
that they all draw from?

The last common upstream was 4.4BSD Lite in 1994 or so. (Yes, that
simplifies a much messier history.)

That came with a version of the Almquist shell. FreeBSD has reworked
that shell extensively since then. OpenBSD replaced it with pdksh in
1996, which IIRC offered better Bourne/POSIX conformance at the
time.

I had a look to see what was available on Debian, and found this <https://packages.debian.org/trixie/mksh>:

mksh is the successor of the Public Domain Korn shell (pdksh), a
Bourne/POSIX compatible shell which is largely similar to the
original AT&T Korn Shell (ksh88/ksh93). It includes bug fixes and
feature improvements, in order to produce a modern, robust shell
good for interactive and especially script use. mksh has UTF-8
support (in string operations and the Emacs editing mode). The
code has been cleaned up and simplified, bugs fixed, standards
compliance added, and several enhancements (for extended
compatibility to other modern shells, as well as a couple of its
own) are available. This shell is Debian Policy 10.4 compliant and
works as /bin/sh on Debian systems (use the /bin/lksh executable)
and is a good rescue and initrd shell (consider the
/bin/mksh-static executable).

Perhaps a better basis for ongoing use than old pdksh code?

Supposedly MKsh (MirBSD Ksh) is the default shell in Android. AFAIK,
all the main BSDs (Free;Open;Net) ship with PDKsh; the MirBSD developer
has a MKsh FAQ which talks about this: http://www.mirbsd.org/mksh.htm .
It is seemingly still actively maintained too even those MirBSD isn't.

-tdc
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2026-08-15, Top Dead Ctr <tdc@invalid.invalid> wrote:

Supposedly MKsh (MirBSD Ksh) is the default shell in Android. AFAIK,
all the main BSDs (Free;Open;Net) ship with PDKsh;

FreeBSD does not. It ships a heavily modified Almquist shell as
/bin/sh.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 14/08/2026 3:08 AM, Johann 'Myrkraverk' Oskarsson wrote:

My next task is then to install NetBSD in a VM.-a I expect I'll do that coming Monday.-a The reason I can do all this is because I'm currently between jobs, and this will be a nice warmup before I start the next dayjob.-a Also, I'm curious if I can do this, and if the NetBSD develop-
ers will accept my changes.

So assuming no hickups, I'll check in on Monday after booting up NetBSD.

Dear comp.unix.shell, Top Dead Ctr, and comp.unix.bsd.netbsd.misc,

I've set up NetBSD in a VirtualBox environment, and verified that the
/cvs/ command is installed. Neither git nor hg are, so far.

I'll check in after checking out the CVS edition of pdksh, or if prob-
lems arise. Followup set to comp.unix.bsd.netbsd.misc, so chosen be-
cause it's also carried by Eternal September. There is no need to
bother comp.unix.shell with what really amounts to /support tickets/
while I familiarize myself with NetBSD, and the pdksh sources.


See you later, and happy ksh!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2