From Newsgroup: comp.unix.shell
On 2026-07-24 19:03, Johann 'Myrkraverk' Oskarsson wrote:
On 24/07/2026 8:34 PM, Janis Papanagnou wrote:
Historically it was typical to have the specific tasks separated...
Like, "echo", "ls", ..., don't actually do enough to justify the
overhead of spawning a new process.
...where newer shells typically have made sensible decisions and built
in functions like 'echo' and 'printf', and added syntactic constructs,
like '[[...]]' that made the former external '[' command (meanwhile
often also built-in) unnecessary.
Concerning 'ls', I don't think that this is primitive enough to become
a built-in; inspect the many options you typically get with it, even
if you only restrict to the POSIX subset. (And for shell scripting you
often don't even need 'ls' since filenames are typically obtained by
other ways and can be obtained even by wildcards in any context.)
(What I'm actually missing is a shell built-in 'stat' command; I think
that would be sensible. But that's just my personal opinion.)
This is trivial, for some value of trivial, by making a Zsh extension.
I've previously written one in C -- of course -- but now the code is
lost.-a What I did for fun was to create a binding for OpenGL.-a It was enough to show a triangle on a screen.-a Today, I'd probably do the same
via SDL3, or even SDL2, and OpenGL rather than GLUT.
And by now, it seems I snipped the part where you mentioned ksh.-a Does
ksh also have a mechanism for dynamic modules?
You can for example write a C-function and load it from Kornshell using
the 'builtin' command.
NAME
builtin - add, delete, or display shell built-ins
SYNOPSIS
builtin [ options ] [pathname ...]
DESCRIPTION
builtin can be used to add, delete, or display built-in commands in
the current shell environment. A built-in command executes in the
current shell process and can have side effects in the current shell.
On most systems, the invocation time for built-in commands is one or
two orders of magnitude less than commands that create a separate
process.
For each pathname specified, the basename of the pathname determines
the name of the built-in. For each basename, the shell looks for a C
level function in the current shell whose name is determined by
prepending b_ to the built-in name. If pathname contains a /, then
the built-in is bound to this pathname. A built-in bound to a
pathname will only be executed if pathname is the first executable
found during a path search. Otherwise, built-ins are found prior to
performing the path search.
If no pathname operands are specified, then builtin displays the
current list of built-ins, or just the special built-ins if -s is
specified, on standard output. The full pathname for built-ins that
are bound to pathnames are displayed.
builtin cannot be invoked from a restricted shell.
I've played with Kornshell built-ins in the past. And it may be useful.
But doing a quick test with my old code strangely fails with ksh93u+m,
I get: "builtin: adding built-ins not supported"! - WTF?
Obviously some things have changed in Martijn Dekker's ksh version. A
quick test of 'builtin' with AT&T ksh93u+ is still working, though.[*]
But Martijn Dekker's ksh93u+m version's 'builtin' man-page (sadly) says
-f lib Not supported.
-l No effect.
where AT&T's ksh93u+ documents verbosely
-f lib On systems with dynamic linking, lib names a shared
library to load and search for built-ins. Libraries
are searched for in ../lib/ksh and ../lib on $PATH
and in system dependent library directories. The
system dependent shared library prefix and/or
suffix may be omitted. Once a library is loaded,
its symbols become available for the current and
subsequent invocations of builtin. Multiple
libraries can be specified with separate
invocations of builtin. Libraries are searched in
the reverse order in which they are specified.
-l List the library base name, plugin YYYYMMDD version
stamp, and full path for -flib on one line on the
The point of the statement in my post (seeking for a builtin 'stat')
was the wish to have it available natively as built-in. The reason is
that I prefer the standard environments of tools and avoid personal or proprietary additions.
Concerning 'stat' I typically have also no performance requirements on
that command, so it's more like a nice-to-have than a strong demand.
Janis
[*] In the past I had suggested to prefer ksh93u+m over ksh93u+, but
meanwhile I'm not that sure any more; there's quite some ksh features
that I had used in the past not any more supported by Martijn's branch.
:-(
--- Synchronet 3.22a-Linux NewsLink 1.2