| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
No real reason for it to be a shell function
|
| |
|
|
|
|
|
|
|
|
| |
It always really annoys me when e.g. the leading dot or leading slash in
pathnames or filenames gets ignored for the purposes of sorting.
I may refine this later on but it seems like a good start for an
approach.
|
| |
|
|
|
|
|
|
|
|
| |
* Move common directory argument checking into helper function
* Tolerate only one directory argument
* Show subcommand in error output
* Don't show help on failed commands, just suggest it
* (Technicality) Fix trailing-newline lossage in subshell function
|
|
|
|
| |
Made the whole thing tidier, actually
|
| |
|
|
|
|
| |
And add an issue about handling complex ones
|
| |
|
| |
|
| |
|
|
|
|
| |
Very niche, but interesting to fix anyway
|
| |
|
| |
|
|
|
|
|
|
| |
POSIX default prompt for ed(1) (after P command) is an asterisk rather
than a colon. I suppose it makes sense to have a distinct character from
the one used for ex(1).
|
| |
|
|
|
|
|
| |
More trouble than they're worth, and looking at my shell history it
looks like I type out the -u all the time anyway
|
| |
|
| |
|
|
|
|
| |
Not portable, and I never use it anyway
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
So it doesn't get installed on systems where I don't use ksh, since it's
mostly not needed
|
|
|
|
| |
I guess this is my life now
|
|
|
|
| |
And hopefully all versions below
|
| |
|
| |
|
|
|
|
| |
As part of a foray into more active use of ksh and derivatives.
|
| |
|
| |
|
| |
|
|
|
|
| |
More trouble than it's worth
|
|
|
|
| |
Wrap it in curly brackets to make it a compound command
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NetBSD sh(1) and possible others don't tolerate a `return` short-circuit
for ENV, which means that because that implementation also sources ENV
if set regardless of whether the shell is interactive or not, all of the
interactive stuff in ~/.shrc and ~/.shrc.d gets uselessly sourced and
loaded up for non-interactive invocations of sh(1).
To work around this, I've set ENV to be a new ~/.shinit file instead,
which sources the ~/.shrc file only if the shell is interactive.
~/.shinit is the filename suggested in the man page for NetBSD sh(1) and
Debian dash(1) as well.
NetBSD's documented behaviour seems to be contrary to POSIX 2003:
> ENV: This variable, when and only when an interactive shell is
> invoked, shall be subjected to parameter expansion (see Parameter
> Expansion ) by the shell, and the resulting value shall be used as a
> pathname of a file containing shell commands to execute in the
> current environment.
No matter; this works fine, and makes non-interactive invocations of
sh(1) on NetBSD much faster.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's not available on default installs of any of the three major
open-source BSDs, and isn't specified by POSIX. I only noticed this
because the implement of sh(1) in NetBSD 7.0 seems to emit errors from
calls to `command -p` to the terminal, regardless of any redirection of
standard output and error:
$ uname -a
NetBSD faeroes 7.0.1_PATCH NetBSD 7.0.1_PATCH (GENERIC.201607220540Z) amd64
$ command -p setterm
setterm: not found
$ command -p setterm >/dev/null
setterm: not found
$ command -p setterm >/dev/null 2>&1
setterm: not found
|
| |
|
|
|
|
| |
Easier to read and does not require a subshell
|
| |
|
|
|
|
| |
Turns out they're POSIX variables!
|
| |
|
| |
|
|
|
|
|
| |
Ancient GNU ls(1) accepts this even if it doesn't use it in the same way
a more modern one does (requiring -S to show the blocks used).
|
| |
|
| |
|
| |
|
| |
|
| |
|