What shall we do with dirs, popd and pushd functions ?

[siteshwar]

These functions are defined by files listed under src/cmd/ksh93/fun directory:

dirs  popd  pushd

These functions are not installed by ninja install. We should either start using them or remove them from repository.

[krader1961]

This is an interesting question. On OpenSuse they get installed in /usr/share/ksh/fun. On Ubuntu they get installed in /usr/share/ksh/functions. On FreeBSD its /usr/local/share/examples/ksh93. On other platforms like Fedora, macOS and OpenBSD they are not installed. Even when installed by the distro they aren't automatically available to use.

Other shells like fish ship with a rich set of functions.

I would argue that long term we should make it easier to ship ksh with useful functions. And while I personally don't like and don't use popd and pushd others might. My vote is to keep them but figure out a ksh compatible scheme similar to how fish does it (i.e., relative to the fish install root) so that these functions are always installed in a well known location which is automatically included in the function autoload path.

[kusalananda]

My vote is to keep them but figure out a ksh compatible scheme similar to how fish does it (i.e., relative to the fish install root) so that these functions are always installed in a well known location which is automatically included in the function autoload path.

As another one who has never seen the point of these functions, I would rather see them installed by default, but not added to the autoload path (and then possibly explicitly added to the autoload path by a distributor or local admin). I.e., as an opt-in option rather than an opt-out option. Fewer default bells and whistles...

[krader1961]

Fewer default bells and whistles...

Sorry, but that made me laugh. You're talking about a shell with a lot of configurable behaviors; e.g., set -o globstar. Which makes writing scripts hard because the distro or user may have changed one of the defaults which can affect the behavior of ksh scripts or functions. I stopped using zsh because I had set an option in my ~/.zshrc which then broke a script that shipped with zsh. Which is precisely why fish doesn't have such configurable behaviors.

[kusalananda]

We're not talking about shell options here, but about a set of three shell functions primarily used in interactive shells (but people will start to use them in scripts too, obviously).

[krader1961]

@kusalananda You seem to be arguing that ksh should never ship with functionality implemented as ksh functions. This is not really about the popd, pushd, and dirs functions. It is about whether or not the base ksh implementation should ever provide core functionality that is implemented by ksh functions rather than written in C. I disagree with your seeming belief that all behavior should be implemented in the core C language.

In my opinion as much functionality as possible should be implemented via the ksh scripting language. Consider the Emacs editor. The vast majority of its behavior is implemented via Emacs LISP code rather than in the implementation language underlying emacs. Consider the realpath command. In the fish shell it is implemented as an autoloaded function that determines whether or not an external command of the same name is available. If an external realpath command is available that is used. Otherwise it defines a realpath function that does nothing more than invoke the builtin. Note that the builtin does not recognize any flags and thus implements only the most basic behavior that 99.9% of the time is all that is needed.

[krader1961]

In other words, @kusalananda, even if we deleted the files in the src/cmd/ksh93/fun directory should we not implement a mechanism by which standard functionality is implemented via autoloaded ksh scripts rather than C code? Shouldn't we be implementing as much functionality as possible via ksh scripts?

If the answer is "no" then I agree the src/cmd/ksh93/fun directory should be deleted. And if the answer is "yes" then it should be renamed and the Meson config modified to include installing those files.

[kusalananda]

Sorry, I must have misread the title of this issue; I thought it was related to these specific functions. You may want to update the title to reflect the fact that it is about any type of ksh93 core functionality provided as a function (which I'm perfectly happy with).

Note that pushd etc. was never part of ksh93's core functionality though.

[krader1961]

@kusalananda: You did not misread the title of this issue. But the question it asks leads to a far more interesting question. Your opinion seems to be that since the functions in that directory have never been automatically made available the answer is to remove those files and never add "core" functionality via ksh scripts/functions. My opinion is that we should implement a standard mechanism for shipping ksh with functions that mimic what would otherwise require a builtin written in the C language. Whether or not those particular functions should be enabled by default is a somewhat different question.

In other words, it is preferable to implement behavior via the ksh scripting language than the C language when possible. Consider the emacs editor and what it would mean if you had to alter its behavior by writing C code rather than emacs LISP code. Implementing as much functionality as possible in the ksh scripting language makes it easier to change that behavior.

[kusalananda]

Sorry for my somewhat snarky tone. I agree that it would be okay to implement core ksh functionality through autoloaded functions (that may be autoloaded by default), but I don't think that the three specific functions are part of that core functionality (a bash user may disagree).

Suggestion:

1. A fun/core subdirectory with functions that are needed to use ksh. These would be autoloaded.
2. A fun/extra subdirectory with functions that may be used if wanted (similar to stuff usually distributed in contrib subdirectories in some other projects).

... or something similar.

[krader1961]

I don't think that the three specific functions are part of that core functionality

You are correct. Those functions have never been made available by default as far as I know. It is possible a particular distro I'm not aware of has done so but that seems unlikely. Relatively few people like or use the functionality provided by pushd/popd (or nextd/prevd). Too, that has never been a part of the standard ksh package. So I concur we should just remove those files. It doesn't seem to me like a good idea to begin making those particular functions available by default given their limited appeal.

So the optimal resolution may be to remove that directory and close this issue. Then open a new issue to discuss how best to make it easy to implement "core" ksh functionality via scripts rather than "C" code.

[kdudka]

I am actually surprised that pushd and popd commands are not available in the Fedora packaging of ksh. They are implemented as built-ins in bash and zsh and commonly used in scripts.

[kdudka]

I do not think they should be removed (without providing a replacement first).

[krader1961]

@kdudka I don't understand your last comment. Whether or not we provide a replacement, such as the cdh command (change dir based on cd history) I added to the fish shell as a saner alternative to these functions, seems irrelevant. Note that I implemented that for fish based on the mcd (menu change dir) command I wrote for ksh more than 20 years ago precisely because I don't like the pushd/popd and nextd/prevd idioms.

My previous comment where I said So the optimal resolution may be to remove ... was made "tongue in cheek." I don't believe we should remove those functions. I believe we should instead always include them as part of the ksh package and automatically make them available to users. Which means establishing a pattern for always installing ksh with well defined locations for autoloaded functions that implement functionality that can be implemented via the ksh language.

[kdudka]

Yes, having them installed by default makes sense to me. But I did not try whether those functions actually work and how much they are compatible with the equally named built-ins available in other shells.

[siteshwar]

I would prefer to have these functions installed and enabled by default. Most of the ksh users should be familiar with these functions as they are supported by other shells. So having these functions enabled by default should not be a surprise.

Another interesting question is if we choose to make these functions disabled by default, what could be done to make them easier to discover ? They should be definitely documented, but may we will also need something similar to fish_config.

[siteshwar]

It may be worth implementing these functions as shell builtins rather than functions.

[DavidMorano]

It may be worth implementing these functions as shell builtins rather than functions.

Since these functions are normally not so performance sensitive, I would prefer to keep them as shell functions. Kurtis also remarked in the past that maybe even more add-ons for KSH should be written in KSH (sort of how EMACS was built up) rather than everything in C.

[krader1961]

If you install from git head you should find that these functions are now automatically available to use:

KSH PROMPT:1: type popd
popd is an undefined function
KSH PROMPT:2: type pushd
pushd is an undefined function
KSH PROMPT:3: type dirs
dirs is an undefined function
KSH PROMPT:4: popd
popd: Nothing to pop.
KSH PROMPT:5: pushd
pushd: No other directory.
KSH PROMPT:6: dirs
~/projects/3rd-party/ast/src/cmd/ksh93/docs

[krader1961]

Contrasted with the ksh93u+ release:

KSH PROMPT:1: type popd
/bin/ksh: whence: popd: not found
KSH PROMPT:2: popd
/bin/ksh: popd: not found

We can decide not to include these "commands" in a standard ksh release. But if we do we should just delete the function definitions. The problem discussed in this issue is that the functions are part of the source code but are undocumented and not enabled by default.

[krader1961]

An interesting question is what, if anything, we want to do about including ksh functions that are not enabled by default in the source for the project. In other words do we want to host third-party functions that are not enabled in a standard ksh installation. If we want to do that there should be a standard way to install and enable those optional ksh functions.

[siteshwar]

I see these functions are installed now, so I will close this issue.