magicant/yash

Yet another shell

Yash: yet another shell

https://magicant.github.io/yash/ This README is also available in 日本語.

Yash, yet another shell, is a POSIX-compliant command line shell written in C99 (ISO/IEC 9899:1999). Yash is intended to be the most POSIX-compliant shell in the world while supporting features for daily interactive and scripting use. Notable features are:

• Global aliases
• Arrays
• Socket redirection, pipeline redirection, and process redirection
• Brace expansion and extended globbing
• Fractional numbers in arithmetic expansion
• Prompt command and command-not-found handler
• Command line completion with predefined completion scripts for more than 100 commands
• Command line prediction based on command history

Yash can be modified/redistributed under the terms of the GNU General Public License (Version 2) but the use of this program is without any warranty. See the COPYING file for the full text of GPL.

Yash is a GitHub-hosted project, and used to be an OSDN-hosted project.

Current Development Status

Yash now fully supports POSIX.1-2008 (IEEE Std 1003.1, 2016 Edition) except for the limitations listed below.

Yash is stable. A maintenance update is released every three months or so. For the change history, see the NEWS file.

Requirements

Yash is supposed to build and run on any POSIX.1-2001 environment with the Software Development Utilities and the C-Language Development Utilities options.

Currently, yash is mainly tested on Fedora, macOS, and Cygwin.

Installation

See the INSTALL file to see how to build and install yash.

After installation, the manual can be viewed by

$ man yash

The manual is also available online at https://magicant.github.io/yash/doc/.

Basic Configuration

Below is a description of basic configuration that you might want to see after installation to get started with yash. For configuration details, see the manual.

Initialization scripts

When yash is started as a login shell, it reads ~/.yash_profile. This file is a shell script in which you define environment variables using the export command.

When yash is started for an interactive use, it reads ~/.yashrc (after reading ~/.yash_profile if it is a login shell also). In this file, you make other configurations such as aliases, prompt strings, key bindings for command line editing, and command-not-found handler. Use the share/initialization/sample file as a template for your ~/.yashrc.

Making yash your login shell

In many Unix-like OSes, a shell must be listed in /etc/shells to be set as a login shell. Edit this file and ensure that the path to yash is written in the file.

Then, run the chsh command in the terminal and follow instructions from the command. Depending on your system, you may have to use another command to change the login shell. See documentation on your system.

Implementation Notes

• In C, a null character represents the end of a string. If input to the shell itself contains a null character, characters following the null character will be ignored.
• The GCC extension keyword __attribute__ is used in the source code. When not compiled with GCC or Clang, this keyword is removed by the preprocessor, so generally there is no harm. But if your compiler uses this keyword for any other purpose, compilation may fail. Additionally, some other identifiers starting with _ may cause compilation errors on some rare environments.
• Some signals are assumed to have the specific numbers: SIGHUP=1 SIGINT=2 SIGQUIT=3 SIGABRT=6 SIGKILL=9 SIGALRM=14 SIGTERM=15
• POSIX disallows non-interactive shells to ignore or catch SIGTTIN, SIGTTOU, and SIGTSTP by default. Yash, however, ignores these signals if job-control is enabled, even if non-interactive.
• File permission flags are assumed to have the specific values:

  0400=user read    0200=user write   0100=user execute
  0040=group read   0020=group write  0010=group execute
  0004=other read   0002=other write  0001=other execute
  

• The character categorization in locales other than the POSIX locale is assumed upward compatible with the POSIX locale.
• The -o nolog option is not supported: it is silently ignored.
• According to POSIX, the value of variable PS1 is subject to parameter expansion. Yash performs command substitution and arithmetic expansion as well on the PS1 value.
• According to POSIX, the command printf %c foo should print the first byte of string foo. Yash prints the first character of foo, which may be more than one byte.
• The return built-in, if executed in a trap, can operate only on a function, script, or loop that has been executed within the trap. This limitation is not strictly POSIX-compliant, but needed for consistent and predictable behavior of the shell.
• Results of pathname expansion is sorted only by collating sequence of the current locale. If the collating sequence does not have a total ordering of characters, order of uncomparable results are unstable. This limitation is not strictly POSIX-compliant, but inevitable due to use of wide characters in the whole shell.

Known Issues

• Line number ($LINENO) may not be counted correctly in and after a complex expansion containing a line continuation.
• Non-ASCII characters may not be correctly handled in some locales on Solaris. This may be worked around by undefining the HAVE_WCSNRTOMBS macro in the config.h header file.

Contributions

Comments, suggestions, and bug reports are welcome at:

• Issue tracking system
• Discussion forum

If you are interested in translation, please refer to TRANSLATING.md.

---

Watanabe, Yuki [email protected]

yash's Issues

Post-prompt command

The $PROMPT_COMMAND variable can be used to execute arbitrary commands just before beginning command line input, but the ability to execute commands immediately after completion of input has not existed to date. Providing such a functionality would allow more complex user scripts to be executed, such as measuring the execution time of the entered command.

Something like $POST_PROMPT_COMMAND would be useful for this purpose.

Yash Throws: yash: parameter `DIRENV_DIR' is not set When Accounted For

Describe the bug
I am currently implementing direnv support into my configuration. I started by adding the direnv shell script offered in the example rc file.

_update_direnv_info() {
	eval "$(
	direnv export json |
		jq -r 'to_entries | .[] |
		if .value == null then
			@sh "unset \(.key)"
		else
			@sh "export \(.key)=\(.value)"
		end'
		)"
}
YASH_AFTER_CD=('_update_direnv_info')

I then wiped up a quick prompt to show either direnv or python status.

_update_direnv_status() {
	direnv_info=$(basename "$(printf "%s" "${DIRENV_DIR}" | tr -d '-')")
	environment_info="\fmt.-(\fd.\fct.${direnv_info}\fd.\fmt.)\fd."
	printf "%s" "${environment_info}"
}

_update_python_status() {
	python_info=$(basename "${VIRTUAL_ENV}")
	environment_info="\fmt.-(\fd.\fct.${python_info}\fd.\fmt.)\fd."
	printf "%s" "${environment_info}"
}

_update_environment_info() {
	if [ -n "${DIRENV_DIR}" ]; then
		_update_direnv_status
	elif [ -n "${VIRTUAL_ENV}" ]; then
		_update_python_status
	fi
}
export PS1='.$(_update_environment_info) \fmt>\fd\fyt>\fd\fct>\fd '

However, every time I run a shell I get the following line yash: parameter DIRENV_DIR' is not set after every command and when I am not in a direnv allowed directory. I did some digging and it is coming from my prompt function _update_direnv_status. From my understanding within POSIX and many other shells, though I may be wrong, this shouldn't be happening because if "${DIRENV_DIR}" is empty the shell will simply move on. Am I missing something?
To Reproduce
Steps to reproduce the behavior:

1. Create new .yashrc
2. Copy the above code into it
3. Launch a new shell
4. See error

Expected behavior
I expect the shell to show nothing related to direnv when not in a direnv allowed directory.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: [e.g. Ubuntu, macOS]
• Version [e.g. 2.55]
• Locale [e.g. en_US.UTF-8]
• If you built yash yourself, also show your configuration parameters.

Additional context
I do not have any additional context other than my current dotfiles located here.

As an update, I found a workaround. If you set

DIRENV_DIR="${DIRENV_DIR:-""}"
VIRTUAL_ENV="${VIRTUAL_ENV:-""}"

you won't get the message. I have not experienced this in other shells, maybe it is a POSIX thing? At any rate, functionally solved. My bad! Though, I have noticied this in scripts and even elsewhere in my configuration. If I have a script that can take optional arguments, or a function or alias that can, such as

_git_add() {
        if [ -z "${1}" ]; then
                        git add . --verbose
        else
                        git add "${@}" --verbose
        fi
}
alias ga='_git_add'

and I run it as 'ga' it should then run git add . --verbose as "${1}" is empty, but instead I get yash: parameter 1' is not set` and it skips to the else statement.

Build warnings on OpenBSD.

If you build on OpenBSD using clang, there are a lot of build warnings.

Most of them are like:

arith.c:503:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]

which are a result of functions catching a "this shouldn't happen" case with assert(false). The assertion would only be hit if assertions are enabled (building without -DNDEBUG).

Would it be better to do something like this?

diff --git a/arith.c b/arith.c
index 9e724f0b..f4be2330 100644
--- a/arith.c
+++ b/arith.c
@@ -20,6 +20,7 @@
 #include "arith.h"
 #include <assert.h>
 #include <errno.h>
+#include <err.h>
 #include <float.h>
 #include <limits.h>
 #include <locale.h>
@@ -498,7 +499,7 @@ long do_long_comparison(atokentype_T ttype, long v1, long v2)
         case TT_EXCLEQUAL:
             return v1 != v2;
         default:
-            assert(false);
+            errx(EXIT_FAILURE, "%s: unreachable", __func__);
     }
 }

Asides from that, there's also:

editing.c:597:14: warning: expression result unused [-Wunused-value]
        INIT(case_func, 0);
             ^~~~~~~~~
./../common.h:52:39: note: expanded from macro 'INIT'
# define INIT(x, dummy_initial_value) x

Thanks

for loop wrong exit status

The following shell script should print 1 according to POSIX:

for x in y; do
  ! continue
done
echo $?

But it prints 0 on yash.

Support for cross compilation

Hey there,

I was wondering if it is possible to support cross compilation for yash.

Currently, it only works if makesignum was built using the host's compiler ($HOSTCC which is often gcc) (not the cross-compilation toolchain's compiler as yash later expects ./makesignum to run on the host):

$MAKE \
  CC=$HOSTCC \
  makesignum

I am also disabling tryexec ():

tryexec () {
    :
}

Orphan trailing backslash in pattern

(Issue migrated from https://osdn.net/projects/yash/ticket/40752)

XCU 2.13.1 Patterns Matching a Single Character:

If a pattern ends with an unescaped backslash, it is unspecified whether the pattern does not match anything or the pattern is treated as invalid.

This means the pattern should not match with any word in bs='\\\'; case word in $bs) echo match; esac. In existing shells, however, one of \, \\ and \\\ matches.

---

Seems the future version of POSIX is going to say that the entire behavior is unspecified in such a case.

https://www.austingroupbugs.net/view.php?id=1234#c4564

If a pattern ends with an unescaped backslash, the behavior is unspecified.

Migration from OSDN

We've been suffering from an availability problem with the OSDN site for the past few months, and it's pretty uncertain that the site will return to normal since it was acquired by OSCHINA. So I'm moving this project to GitHub.

Previously, GitHub was only considered a mirror, but now it is the main host of this project.

• Update README 76ac86e
• Host the website on gh-pages 54cb782
• Host the manpage on gh-pages ef89c08 9f79c75
• Redirect https://yash.osdn.jp to gh-pages (if possible)
• Update the manpage 082d62f
• Update the website contents 5a7e119
• Migrate wiki pages
  • Committing
  • FrontPage
  • HowToTranslate → TRANSLATING.md
  • JapaneseEnglishTranslation (Obsolete)
  • Release → RELEASING.md
  • Yashrc/Intro (Obsolete)
  • Yashrc/Prompt (Obsolete)
• Update the Jenkins configuration for the existing jobs
• Automate more tests on Jenkins and update RELEASING.md
• Migrate OSDN tickets to GitHub issues (if possible)
• Update any remaining references to OSDN in the code repository a108297
• Update the OSDN project description to redirect visitors to GitHub

Many linting errors on man page.

OpenBSD's mandoc command has a linter for shaking bugs out of man pages.

If you run mandoc -Tlint yash.1, you get lots of linter errors.

Some are style-related, like:

mandoc: yash.1:3289:305: STYLE: input text line longer than 80 bytes: Local variables may ...

but others are proper warnings, like:

mandoc: yash.1:12733:2: WARNING: skipping paragraph macro: sp after SS

I also notice that when you build an OpenBSD package of yash it says:

/usr/local/pobj/yash-2.55/fake-amd64/usr/local/man/ja/man1/yash.1: No one-line description, using filename "yash"

That last one I've seen before and have fixed like this

(I don't know if any of this matters to you, but I thought I'd mention it)

Thanks

Hexadecimal escape sequence in printf built-in

(Feature request migrated from https://osdn.net/projects/yash/ticket/43146)

This is not required by POSIX but is implemented in other implementations.

printf "\x66\x65\n"

Numeric brace expansion containing parameter

(Issue migrated from https://osdn.net/projects/yash/ticket/40711)

We now support expansion like this:

$ set -o braceexpand
$ d=. o=1
$ echo {1${d}${d}3} {${o}..3}
1 2 3 1 2 3

This may possibly be a cause of unexpected expansion, for example, like echo {${var}} where var='1..3'.

On the other hand, it would still be useful if the range of numeric brace expansion could be specified by parameters: echo {${from}..${to}}

So my current opinion is that the braces and dots must be literal (not from parameter expansion) but the numbers can be a parameter.

(This behavior is different from that of other shells, though...)

Declaration utility

(Issue migrated from https://osdn.net/projects/yash/ticket/46042)

The notion of "declaration utility" is going to be added in the next version of POSIX.

• https://www.austingroupbugs.net/view.php?id=351
• https://www.austingroupbugs.net/view.php?id=1393
• https://www.austingroupbugs.net/view.php?id=1535

We need to implement it when the standard is finalized.

Considerations:

• Should declaration utilities be recognized at parse-time or run-time?
• How do assignments in arguments interact with normal assignments? (e.g. a=foo export a=bar)
• Should we support array assignment like export a=(1 2 3)? How?

fsplit-p.tst: export IFS influences run-test.sh

When the fsplit-p.tst exports IFS this variable also effects run-test.sh.

yash/tests/fsplit-p.tst

Line 14 in f5bbaad

export IFS=X

run-test.sh assumes the default IFS to correctly split diff_opt.

yash/tests/run-test.sh

Line 311 in f5bbaad

if ! diff $diff_opt - "$out_file" <&4; then

yash/tests/run-test.sh

Line 331 in f5bbaad

if ! diff $diff_opt - "$err_file" <&5; then

With the changed IFS -U 10000 is passed as a single argument to diff (and not split as normally). The diff implementation of coreutils ignores this error but the one from busybox is more strict.

IFS should probably be unset before word splitting is used in run-test.sh.

Non-interactive shell should not ignore stop signals

(Issue migrated from https://osdn.net/projects/yash/ticket/40890)

POSIX says sh should ignore TSTP, TTIN and TTOU only when it is interactive.

Currently yash ignores them when job-controlling, no matter whether interactive or not.

Result of tilde expansion in nested parameter expansion

(Issue migrated from https://osdn.net/projects/yash/ticket/40707)

Currently, the result of ~ and ${unset-~} are not subject to field splitting or pathname expansion, but that of ${${unset-~}} is. Can we prevent expansion for the latter, too?

test_oE 'result of tilde expansion in nested parameter expansion'
HOME='/path/with  $space$(:)`:`$((1))' IFS=' /'
echoraw ${${u-~}}
HOME='*'
echoraw ${${u-~}}
__IN__
/path/with  $space$(:)`:`$((1))
*
__OUT__

---

In the current implementation, the outer expansion receives the result of the inner expansion after it has performed quote removal.
To honor the character origin of the inner expansion, however, the outer expansion needs to receive the result without quote removal. This will affect the character count in the outer expansion; for example, should ${${unset-"~"}[1]} expand to a double-quote or tilde?

b$ is printed when resizing kitty

Describe the bug

kitty is a terminal emulator supporting window split and layouts (horizontal and vertical splits). When the size of a single pane is changed, a new line with b$ is printed on another one. Interestingly this happens only if I have some input in the prompt. Kitty has integrations with some shells, but I tried the same with some other shells without integration and it doesn't seem to happen.

To Reproduce
Steps to reproduce the behavior:

1. Open kitty with yash
2. Enter something into the prompt
3. Split the view (Ctrl-Shift-Enter by default)
4. Go to the other pane for example by clicking on it
5. Start resizing (Ctrl-Shift-R by default)
6. Make the pane shorter or taller (s or t).

Expected behavior
Resizing works without superfluous characters being printed.

Screenshots

Environment (please complete the following information):

• OS: Slackware 15.0
• Version: 2.55
• Locale de_DE.UTF-8

Alphabetic sequential brace expansion

(Feature request migrated from https://osdn.net/projects/yash/ticket/41105)

Currently yash's brace expansion does not support the {a..c} form which expands to a b c, for example. Let's support this for compatibility with other shells.

Searching XDG directories for initialization files

(Feature request migrated from https://osdn.net/projects/yash/ticket/46546)

It might be helpful if the shell honors the $XDG_CONFIG_HOME variable when looking for initialization scripts (profile and rcfile).

---

Unresolved questions

• How can the user set the $XDG_CONFIG_HOME variable before the shell gets started? Typically, user-specified variables are set in the initialization scripts. It does not make sense for a script to set a variable that defines its own pathname.

'typeset' and family accept invalid identifiers

(This issue was originally filed at https://osdn.net/projects/yash/ticket/39386 by @McDutchie)

$ readonly a\ b=c
$ readonly a\ b=d
readonly: $a b is read-only
$ echo ${a b}
syntax error: invalid character ` ' in parameter expansion

If that is an invalid expansion, then 'readonly' should not have succeeded either.

$ export a\ b=c
$ env | grep ^a\ b=
a b=c

Allowing identifiers with spaces to be exported also does not seem like a good thing.

Not killing unrelated processes

(Issue migrated from https://osdn.net/projects/yash/ticket/47669)

cf. https://www.austingroupbugs.net/view.php?id=1585

It might possibly be useful to add an option that makes the kill built-in send a signal only to the shell's direct child processes. It ensures the signal is not sent to an unrelated process that has reused the process ID of a child process of the shell.

Note that it only works for direct children of the shell. The shell cannot detect grandchildren.

Multi-process pipelines will not benefit from this feature as the signal can be sent only to the last component of the pipeline when you pass the expansion of $! to the kill built-in.

Also, this would not be very useful for job-controlled jobs as they can safely be killed by the job ID notation.

doas completion

doas is a simpler alternative to sudo, used by some Linux distributions like Alpine.

It would be great if completing the command after doas (similar to how yash completes any command for which completion is available after typing in sudo) was supported, and a new release featuring this could be made.

Thank you.

Filtering completion candidates incrementally

(Feature request migrated from https://osdn.net/projects/yash/ticket/38262)

Assume a user hits the Tab key to list command line completion candidates then starts typing one of the candidates. It would be useful if the shell hides candidates that do not match (part of) the candidate being typed. This filtering would be the most useful if applied each time the user types a character after completion.

filename completion with tab inserts additional backslash if started from one

Describe the bug
when pressing tab after a backslash in a filename, a second backslash is added, making the filename iunvalid

To Reproduce

touch "hello space world.txt"
ls hello<TAB>

filename gets expanded to hello\ space\ world.txt
use backspace to delete everything after the last backslash, so you're left with:
ls hello\ space\. hit tab again. the completed filename is now hello\ space\\ world.txt. this makes the escaped filename invalid.

Expected behavior
if hitting tab after a backslash that's not in the original filename: either don't autocomplete at all, or remove the last backslash before completion.

Environment (please complete the following information):

• OS: sabotage linux
• Version 2.55
• Locale C

AddressSanitizer: negative-size-param in decompose_paths

Describe the bug
yash crashes on start when built with AddressSanitizer.

With the following debug patch applied, variable n passed to wcsnrtombs() is -1 in the last round of decomposing PATH, resulting in a crash in AddressSanitizer.

diff --git a/strbuf.c b/strbuf.c
index 9666b11c..b866e724 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -191,6 +191,7 @@ wchar_t *sb_wcsncat(xstrbuf_T *restrict buf,
 #if HAVE_WCSNRTOMBS
     for (;;) {
         const wchar_t *saves = s;
+        xprintf("sb_wcsncat: str=%ls, nwc=%ld, len=%ld\n", s, n, buf->maxlength - buf->length);
         size_t count = wcsnrtombs(&buf->contents[buf->length],
                 (const wchar_t **) &s, n,
                 buf->maxlength - buf->length, ps);
@@ -210,6 +211,7 @@ wchar_t *sb_wcsncat(xstrbuf_T *restrict buf,
         }
         sb_ensuremax(buf, add(buf->maxlength, MB_CUR_MAX));
     }
+    xprintf("sb_wcsncat: done, str=%ls\n", s);
     assert(buf->contents[buf->length] == '\0');
     return (wchar_t *) s;
 #else

Output:

sb_wcsncat: str=/usr/bin:/bin:/usr/sbin:/sbin, nwc=8, len=15
sb_wcsncat: done, str=(null)
sb_wcsncat: str=/bin:/usr/sbin:/sbin, nwc=4, len=15
sb_wcsncat: done, str=(null)
sb_wcsncat: str=/usr/sbin:/sbin, nwc=9, len=15
sb_wcsncat: done, str=(null)
sb_wcsncat: str=/sbin, nwc=-1, len=15

To Reproduce
Steps to reproduce the behavior:

1. Run ./configure without -fsanitize=address in CFLAGS and LDFLAGS
2. Modify Makefile by hand, adding -fsanitize=address to both flags
3. make yash
4. PATH="/usr/bin:/bin:/usr/sbin:/sbin" ./yash
5. See error
6. Apply debug patch and try again
7. See nwc=-1

Expected behavior
Yash does not crash with AddressSanitizer.

Screenshots
(without patch)

./yash
yash(17524,0x7ff85e79ab40) malloc: nano zone abandoned due to inability to reserve vm space.
=================================================================
==17524==ERROR: AddressSanitizer: negative-size-param: (size=-1)
    #0 0x10196877b in wcsnrtombs+0x50b (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x7d77b)
    #1 0x100e42082 in sb_wcsncat strbuf.c:194
    #2 0x100e44e0a in malloc_wcsntombs strbuf.c:513
    #3 0x100e4bc29 in malloc_wcstombs strbuf.h:448
    #4 0x100e492d7 in decompose_paths variable.c:1153
    #5 0x100e48cf0 in init_environment variable.c:278
    #6 0x100e70aaa in main yash.c:144
    #7 0x7ff81ae103a5 in start+0x795 (dyld:x86_64+0xfffffffffff5c3a5)

0x61d000001c54 is located 2004 bytes inside of 2080-byte region [0x61d000001480,0x61d000001ca0)
allocated by thread T0 here:
    #0 0x1019c9400 in malloc+0xa0 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0xde400)
    #1 0x7ff81b0a1a2f in wcsdup+0x1e (libsystem_c.dylib:x86_64+0x69a2f)
    #2 0x10199ce2f in wcsdup+0xcf (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0xb1e2f)
    #3 0x100e48985 in init_environment variable.c:267
    #4 0x100e70aaa in main yash.c:144
    #5 0x7ff81ae103a5 in start+0x795 (dyld:x86_64+0xfffffffffff5c3a5)

SUMMARY: AddressSanitizer: negative-size-param (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x7d77b) in wcsnrtombs+0x50b
==17524==ABORTING

Environment (please complete the following information):

• OS: macOS
• Version commit bd1fd3f
• Locale en_US.UTF-8
• Built with clang version 17.0.5 and -g -O0 -fsanitize=address

Additional context
N/A

Autofill the command line

(Feature request migrated from https://osdn.net/projects/yash/ticket/43094)

Hello, yash is excellent, thank you for it. One alias I like is the following history alias:

alias h="history | sort --reverse --numeric-sort | fzy | sed 's/\[[:digit:]]*[[:space:]]*//' | tr -d '\n' | xclip -selection clipboard"

That uses fzy to search the history, and when something is selected it gets copied to the clipboard. However, instead of copying it to the clipboard, I would like to send it to yash's command line prompt, so I can press enter and run the command, or edit the command before running it.

Is there a way to automatically fill in the command line prompt?

Accidentally pressing escape will wreck interactive input until next Ctrl+C

Describe the bug
While typing a command, if you press escape on your keyboard, the input state gets garbled.

To Reproduce
Steps to reproduce the behavior:

1. yash --posix
2. Type anything (i.e. laz as the start of lazygit)
3. Press escape
4. Press any other key. Depending on what key is pressed, different things will happen.

Expected behavior
Pressing escape will do nothing. Fish works like I would expect.

Environment (please complete the following information):

• OS: Fedora
• Version 2.56.1
• Locale en_US.UTF-8

Additional context
The behavior is slightly different when using the default yashrc, but I haven't narrowed down exactly why. You can see my configuration here.

I use keyd to bind my capslock key to escape when pressed and control when held, so I accidentally press escape quite often.

seg fault in alt+c completion

Describe the bug

I can sometimes get a seg fault by repeatedly pressing alt+c to accept suggested completions.

To Reproduce

1. start typing a command until yash offers a suggestion. I typed ls and yash offered ls /123.
2. repeatedly type alt+c to accept arguments. I think i may have pressed enter after.
3. seg fault sometimes.

Here's a low-quality backtrace:

Program received signal SIGSEGV, Segmentation fault.
memmove () at /usr/src/lib/libc/arch/amd64/string/memmove.S:88
88		movsq
Current language:  auto; currently asm
(gdb) bt
#0  memmove () at /usr/src/lib/libc/arch/amd64/string/memmove.S:88
#1  0x000001fc7a13b49a in wb_replace_force () from /usr/local/bin/yash
#2  0x000001fc7a15776e in cmd_self_insert () from /usr/local/bin/yash
#3  0x000001fc7a157438 in le_invoke_command () from /usr/local/bin/yash
#4  0x000001fc7a163640 in le_readline () from /usr/local/bin/yash
#5  0x000001fc7a122b25 in input_interactive () from /usr/local/bin/yash
#6  0x000001fc7a12a44a in next_token () from /usr/local/bin/yash
#7  0x000001fc7a12807a in parse_command_list () from /usr/local/bin/yash
#8  0x000001fc7a127dae in read_and_parse () from /usr/local/bin/yash
#9  0x000001fc7a146c38 in parse_and_exec () from /usr/local/bin/yash
#10 0x000001fc7a146aee in exec_input () from /usr/local/bin/yash
#11 0x000001fc7a1468dc in main () from /usr/local/bin/yash

I'll try to get a better one with symbols on master.

Environment (please complete the following information):

• OS: OpenBSD-current
• Version 2.55
• Locale en_US.UTF-8

Per-session history

(Feature request migrated from https://osdn.net/projects/yash/ticket/40964)

Is your feature request related to a problem? Please describe.
Currently, all yash processes share a single command history if they share the same $HISTFILE value. This behavior can be unhelpful if the user is doing different tasks in separate shell sessions, especially working in different directories.

Describe the solution you'd like
There should be a way to keep separate command histories for different shell sessions while still having a shared $HISTFILE value so that the history is merged and saved in the file when the shell exits.

---

https://osdn.net/projects/yash/ticket/40964#comment:3863:40964:1613307018

I was thinking of adding two options to change the shell's behavior. The first option can be used to disable the shell from reading new commands from the history file written by other shell instances. The second option makes the shell write the history when the shell exits rather than each time a new command is entered.

The second option, however, turned to be harder to implement than I thought at first. More precisely, changing when to write the history is not that hard, but it introduces possibility of accidental loss of history since the shell might be killed by a signal before it writes the history on exit. For safety, the shell should install signal handlers that catch signals that would kill the shell, and that will complicate the existing signal handling logic.

For now, I'm considering adding only the first option rather than implementing the both options at once.

`typeset -fp` may print ill-formed command substitution

(Issue migrated from https://osdn.net/projects/yash/ticket/43410)

Describe the bug
typeset -fp prints command substitutions in the $() format even if the original function definition contained them in the backquoted form. In doing so, some quotations may not retain their exact semantics.

To Reproduce

$ foo() { `'`; }
$ typeset -fp foo
foo()
{
   $(')
}

$(') does not parse the same as the original backquoted command substitution.

Expected behavior
The printed function body should include the same backquoted command substitution.

Cannot expand `${0_1}`

(Issue migrated from https://osdn.net/projects/yash/ticket/39289)

I'm not sure if the paraneter name 0_1 is acceptable or not in the first place, but the current behavior is inconsistent anyway.

$ typeset 0_1=foo
$ export 0_1
$ printenv 0_1
foo
$ echo ${0_1?}
yash: parameter `0_1' is not set

Maybe there should be a way to expand a variable with an arbitrary name possibly including unusual characters. See also #28.