summary refs log tree commit diff
path: root/bin/dash (follow)
Commit message (Collapse)AuthorAge
* Merge dash v0.5.11.4June McEnroe2021-06-20
|
* Check in dash autogen files for realJune McEnroe2021-04-25
|
* Copy automake filesJune McEnroe2021-04-25
|
* Revert "Check in dash autogen files"June McEnroe2021-04-25
| | | | | | This reverts commit 84094668ce6873b0922940b2d863ee852839e9f2. Well apparently this just created symlinks to system files. Stupid.
* Check in dash autogen filesJune McEnroe2021-04-04
| | | | So that I don't need to install autoconf/automake to build it.
* Warn twice about stopped jobsJune McEnroe2021-02-04
| | | | | | Not really sure why this previously set job_warning to 2 rather than 1. Anyway I often just press ^D again after the warning without really thinking, so do it twice.
* Set H_SETUNIQUEJune McEnroe2020-12-28
|
* Fix dash Makefile compatibility with BSD makeJune McEnroe2020-12-23
|
* Fix multi-line prompts when right prompts are usedJune McEnroe2020-12-23
| | | | | | editline does not render a multi-line PS1 correctly when RPS1 is also set. To work around this, return only the last line of the cached prompt to editline, and print the leading lines separately inside setprompt.
* Add RPS1 and RPS2 right prompt variablesJune McEnroe2020-12-23
|
* Cache the expanded prompt for editlineJune McEnroe2020-12-23
| | | | | | | | | | | | | | | | | | | Previously, the prompt would be expanded every time editline called the getprompt callback. I think the code may have been written assuming that editline only calls getprompt once per prompt, but it may actually call it many times, for instance every time you type backspace. This results not only in slower editing from expanding complex prompts repeatedly, it also consumes more and more stack memory each time getprompt is called. This can be seen by setting PS1 to some command substitution, typing many characters at the prompt, then holding backspace and observing memory usage. Thankfully all this stack memory is freed between prompts by the stackmark calls around el_gets. This change causes prompt expansion to always happen in the setprompt call, as it would when editline is disabled, and a cached copy of the prompt is saved for getprompt to return every time editline calls it. Since getprompt is no longer doing expansion, the stackmark calls surrounding el_gets can be removed.
* Bind libedit's secret filename completion functionJune McEnroe2020-12-22
| | | | | | | | | | Check if the FreeBSD (and by extension macOS) _el_fn_sh_complete version of the function exists, which does shell escaping of completed filenames before _el_fn_complete learned to. Tab is bound after calling el_set() and el_source() since the default bindings set tab to something else, and it should always be filename completion in the shell.
* Build with libedit by defaultJune McEnroe2020-12-22
|
* Fail if building --with-libedit and can't find libeditJune McEnroe2020-12-22
| | | | | Previously, configure --with-libedit would only fail in the case where libedit is available but its header file histedit.h is not.
* Merge commit '9e55e38997ed4d6998af9e113e215a926c24988e' as 'bin/dash'June McEnroe2020-12-22
From tag 'v0.5.11.2'.
600 in dtchJune McEnroekernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=6e1b4fdad5157bb9e88777d525704aba24389bee" ... > 2014-06-11 15:34:51 (80.4 MB/s) - ‘no-cache’ saved [4767] Patch is complete, without truncation. Next hit, with cache in place: > mricon@nikko:[/tmp]$ wget -O yes-cache > "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=6e1b4 > fdad5157bb9e88777d525704aba24389bee" ... > 2014-06-11 15:35:01 (17.0 MB/s) - ‘yes-cache’ saved [4096/4096] Length truncated to 4096. The cache on disk looks truncated as well, so the bug must me during the process of saving cache. The same is true for larger patches: > mricon@nikko:[/tmp]$ wget -O no-cache > "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=2840c566e95599cd60c7143762ca8b49d9395050" ... > 2014-06-11 15:41:33 (1.07 MB/s) - ‘no-cache’ saved [979644] 979644 bytes with a cache-miss > mricon@nikko:[/tmp]$ wget -O yes-cache > "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=2840c > 566e95599cd60c7143762ca8b49d9395050" ... > 2014-06-11 15:41:46 (1.05 MB/s) - ‘yes-cache’ saved [978944] 978944 (956KB exactly) with a cache-hit Since the "html" functions use raw write(2) to STDIO_FILENO, we don't notice problems with most pages, but raw patches write using printf(3). This is fine if we're outputting straight to stdout since the buffers are flushed on exit, but we close the cache output before this, so the cached output ends up being truncated. Make sure the buffers are flushed when we finish outputting a patch so that we avoid this. No other UIs use printf(3) so we do not need to worry about them. Actually, it's slightly more interesting than this... since we don't set GIT_FLUSH, Git decides whether or not it will flush stdout after writing each commit based on whether or not stdout points to a regular file (in maybe_flush_or_die()). Which means that when writing directly to the webserver, Git flushes stdout for us, but when we redirect stdout to the cache it points to a regular file so Git no longer flushes the output for us. The patch is still correct, but perhaps the full explanation is interesting! Reported-by: Konstantin Ryabitsev <mricon@kernel.org> 2014-06-28ui-log: ignore unhandled argumentsJohn Keeping If you search for a bogus range string here: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/ Using something like "range" and "qwerty123456", it returns an "Internal Server Error" and the following in the logs: > [Tue Jun 10 17:45:32 2014] [error] [client 172.21.1.6] fatal: > ambiguous argument 'qwerty123456': unknown revision or path not in the > working tree., referer: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ > [Tue Jun 10 17:45:32 2014] [error] [client 172.21.1.6] Use '--' to > separate paths from revisions, like this:, referer: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ > [Tue Jun 10 17:45:32 2014] [error] [client 172.21.1.6] 'git <command> > [<revision>...] -- [<file>...]', referer: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ > [Tue Jun 10 17:45:32 2014] [error] [client 172.21.1.6] Premature end > of script headers: cgit, referer: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ The cache will kick in, so if you search for the same string again, it'll show an empty range, so you have to change the bogus strings each time. This is because we just pass the arguments straight to Git's revision parsing machinery which die()s if it cannot parse an argument, printing the above to stderr and exiting. The patch below makes it a bit friendlier by just ignoring unhandled arguments, but I can't see an easy way to report errors when we can't parse revision arguments without losing the flexibility of supporting all of the revision specifiers supported by Git. Reported-by: Konstantin Ryabitsev <mricon@kernel.org> 2014-06-28git: update for git 2.0Christian Hesse prefixcmp() and suffixcmp() have been remove, functionality is now provided by starts_with() and ends_with(). Retrurn values have been changed, so instead of just renaming we have to fix logic. Everything else looks just fine. 2014-04-17remove trailing whitespaces from source filesChristian Hesse 2014-04-12git: update to 1.9.2Christian Hesse Everything works just bumping the version in Makefile and commit hash in submodule. No code changes required. 2014-04-05Fix cgit_parse_url when a repo url is contained in another repo urlJulian Maurice For example, if I have two repos (remove-suffix is enabled): /foo /foo/bar http://cgit/foo/bar/ is interpreted as "repository 'foo', command 'bar'" instead of "repository 'foo/bar'" 2014-03-20Makefile: use more reliable git tarball mirrorJason A. Donenfeld 2014-03-20git: update to 1.9.1Christian Hesse