chrisant996 / clink Goto Github PK

In previous versions of clink (and in bash) alt-d deletes forward a word (same as ctrl-delete). However in 1.1.17 it seems to instead remove the whole line and delete it from the history. Not sure if this is a bug or intentional change, but how can I restore the old behavior?

When history.dupe_mode = "erase_prev" and history.shared is false:

History entries can temporarily disappear in some instances.

REPRO:

• Have history that includes echo hello.
• Start two Clink instances.
• In instance 1,
  • press Up until the echo hello history entry is shown.
  • press Enter.
• Now the master history has echo hello removed, and echo hello was added to instance 1's session history.
• In instance 2,
  • press Enter.
  • press Up repeatedly.

EXPECTED RESULT: echo hello will shown up in the available history.
ACTUAL RESULT: it won't be present again until after instance 1 exits and its session histories are appended to the master history.

And I've been collecting notes about the behavior of the program since, but the bottomline is that it "works great!" and is already in its current state, a huge improvement and an excellent replacement over the v0.4.9 that I was using (n.b.: never really used martin's v1.0.x more than a few hours back in the day).

With that said, I find it hard to give proper bug reports since you're commiting every day constantly, so instead of sitting on these shitty notes/bugs I made, I'll just dump them below in no particular order and hope they might be useful to you somehow:

Potential Bugs:
* alt+<n> followed by alt+ctrl+y isn't working
* arrow keys don't exit `reverse-search-history` like in bash (need to press ctrl+j)
* `history <n>` returns errorlevel 1?
* doskey macros separated by a `$T` echoes the next cmdline
* doskey macros beggining with `$T` are not recognized as valid command (works in vanilla cmd.exe)
* alt+home behavior is inconsistent (only works after alt+up is performed and then stops working)
* `clink history delete <n>` returns a CRT error on my Win8.1:
	---------------------------
	Microsoft Visual C++ Runtime Library
	---------------------------
	Assertion failed!

	Program: C:\Apps\Diversos\Clink\clink_dll_x64.dll
	File: C:\repos\clink\clink\app\src\history\history_db.cpp
	Line: 757

	Expression: false

	For information on how your program can cause an assertion
	failure, see the Visual C++ documentation on asserts

	(Press Retry to debug the application - JIT must be enabled)
	---------------------------
	Abort   Retry   Ignore   
	---------------------------

I have a few feature requests as well, but I'll leave those to a separate issue (that is, if you're willing to deal with (mostly cosmetic) requests at this point).

cmder #2451 observed that the settings and history don't migrate from old Clink.

Once v1.1.x is ready to integrate with Cmder, it may be constructive to profile the startup and identify what's causing the slowness. It could be an issue with Clink, an issue with Cmder, or some combination of both.

System: Windows 10 - 10.0.19042.685
Clink: 1.1.11 bd8deb

Sometimes it works, but later when I start your new clink by clicking clink.bat:

see the attatchment for detail:

clink_crash_report.zip

Hope it could be fixed.

With the new version of Cmder when trying to start a DOS prompt, thus using Clink, the clink_x64.exe is blocked by the security software on my laptop.
I've tried various versions and have gotten the block on all of them except 1.1.17. 1.1.10, 1.1.13, and 1.1.20 were tried and got the block.
The info in the security software says: "Violation: OopThreadCreate: PID: ####, Application <path_to_clink_exe>".

I would guess there's some new feature that is trying to spawn threads outside of the clink exe?

Hi,
first thanks for picking up this project and make updates to it.
I've been using clink 0.4.9 for a while and wanted to try this new version.

But it seems to not work as intended on my machine.

Clink v0.4.9 [git:2fd2c2] Copyright (c) 2012-2016 Martin Ridgers
http://mridgers.github.io/clink

R:\clink_0.4.9>cd
R:\clink_0.4.9

R:\clink_0.4.9>

and the new version simply doesn't show any prompt or even provide tab completion

Clink v1.1.8.f031c7 Copyright (c) 2012-2018 Martin Ridgers Portions
Copyright (c) 2020 Christopher Antos
http://github.com/chrisant996/clink

cd
R:\clink.1.1.8.f031c7

I saw the clink.promptfilter in the docs and tried setting if to False but nothing changed. What am I missing?

p.s: I'm on Win7 [Version 6.1.7601]
p.s.2 It's related to #31 since I experienced it at the same way and than tried to investigate if it was a 'scoop' problem, or a 'conemu' problem, so I tried running clink clean in cmd and the same thing happended.

This is more of a question than a feature request, but I'm not seeing much of any output in the logs when it comes to loading and executing lua scripts. I'm attempting to start the process of migrating Cmder to use your fork, but I don't even know here to begin because I'm not seeing any errors in the logs even when the scripts are obviously failing. How can I get better debug information on where the lua scripts are failing?

Calling cd "Progr + TAB in the C:\ directory expands to cd Program (without the quote) because it registers that there is a folder named ProgramData along with the other two Program Files folders. The default behaviour should be to maintain the quote. Another alternative is to revert back to the original CMD method of escaping the slash.

Thoughts?

Readline has trouble positioning the cursor correctly anywhere in the line earlier than the last surrogate pairs entered. I can't tell yet if that's a Readline issue or a Clink issue. It works in git-bash, but that isn't conclusive as to where the problem lies.

Maybe the wcwidth() implementation in Clink is outdated?

REPRO:

• Start Microsoft Terminal
• Open a CMD console tab
• Run clink inject
• Type echo
• Copy/paste an emoji from getemoji
• Press the Home key

EXPECTED: Cursor should be flashing on the e.
ACTUAL: Cursor is flashing on the c.

Typing causes text to be inserted before the e, which shows that the cursor position was internally correctly on the e, even though the flashing cursor appeared on the c.

The .. shortcut results in an error '..' is not recognized as an internal or external command, operable program or batch file in C:\ or any directory directly below, such as C:\Users or C:\Program Files. It does work with a trailing slash ..\ however, and more dots like ... does work. In all deeper directories .. works without a slash.

• nullcmd "abc %usercomplete => mistakenly becomes nullcmd "%USER (loses the "abc ).
  • Bash ignores everything inside quotes, but Clink should handle env var completions inside quotes.
• nullcmd "abc def"complete => mistakenly becomes nullcmd "abc def"abc def".
  • Bash also mishandles this case, but in a different way; it becomes nullcmd abc\ def.

(Both are caught by the tests. But they're relatively benign, and they're complicated enough to solve that I need to do a bit of planning first. So I'm temporarily letting the 2 test failures ride for now.)

Issue #49 gave a great example.

M-C-u and "\M-\C-u" both map to Alt+Ctrl+u.
However, "M-C-u" is the literal keys M-C-u.

It can be hard to notice the mistake when reading (or writing) an inputrc file.

One way Clink could help is for the clink-show-help command (Alt+h) to print a warning about key sequences that start with "M- or "C- in emacs mode (but not in vi mode, since vi mode works differently and those might be real key bindings there).

Readline's use of mbrtowc() (and probably everything else) expects that wchar_t is 4 bytes.

Visual Studio wchar_t is 2 bytes, and its mbrtowc() consumes the surrogate pairs from the UTF8, but mangles the output.

This prevents Readline from being able to handle surrogate pairs correctly while editing. This might be the root cause of #26 (can't tell yet).

Sample program that demonstrates the problem:

#include <stdio.h>
#include <locale.h>
#include <string.h>
#include <wchar.h>
#include <uchar.h>

//#define USE_CHAR32
#ifdef USE_CHAR32
# define chartype char32_t
# define mbrtochar mbrtoc32
#else
# define chartype wchar_t
#define mbrtochar mbrtowc
#endif

int main(void)
{
    setlocale(LC_ALL, "en_US.utf8");
    mbstate_t state;
    memset(&state, 0, sizeof state);
    char in[] = u8"z\u00df\u6c34\U0001F34C"; // or u8"zß???"
    const size_t in_sz = sizeof in / sizeof *in;

    printf("Processing %zu UTF-8 code units: [ ", in_sz);
    for(size_t n = 0; n < in_sz; ++n) printf("%#x ", (unsigned char)in[n]);
    puts("]");

    printf("size of chartype is %zu\n", sizeof(chartype));

    chartype out[in_sz];
    char *p_in = in, *end = in + in_sz;
    chartype *p_out = out;
    size_t rc;
    while((rc = mbrtochar(p_out, p_in, end - p_in, &state)) > 0)
    {
        p_in += rc;
        p_out += 1;
    }

    size_t out_sz = p_out - out + 1;
    printf("into %zu wchar_t units: [ ", out_sz);
    for(size_t x = 0; x < out_sz; ++x) printf("%#x ", (unsigned int)out[x]);
    puts("]");
}

wchar_t yields:

Processing 11 UTF-8 code units: [ 0x7a 0xc3 0x9f 0xe6 0xb0 0xb4 0xf0 0x9f 0x8d 0x8c 0 ]
size of wchar_t is 2
into 5 wchar_t units: [ 0x7a 0xdf 0x6c34 0xfffd 0 ]

char32_t yields:

Processing 11 UTF-8 code units: [ 0x7a 0xc3 0x9f 0xe6 0xb0 0xb4 0xf0 0x9f 0x8d 0x8c 0 ]
size of wchar_t is 4
into 5 wchar_t units: [ 0x7a 0xdf 0x6c34 0x1f34c 0 ]

If I'm not mistaken, using the old-menu-complete command should cycle through any .bat files.

I use the Proof of Concept 3 version and copied the files to old clink install folder and replaced all files. Now the normal cmd worked, but as I use the android cmd often, I reverted to clink from martin.

Here is command line of android prompt:

"C:\Windows\System32\cmd.exe" /K cd "C:\Program Files (x86)\Android\android-sdk" & set PATH=%PATH%;"C:\Program Files (x86)\Android\android-sdk\platform-tools"

You can get the standalone platform tools without Xamarin workload of VS to repro and debug it.

Colored completions (see below) were working in version 1.0.0.a1 (before the fork). Are they "gone" are work in progress?

There are several problems with vi_mode and input key sequences that start with ESC. E.g. Alt+key, Ctrl+Alt+key, and the Escape key.

I'm working on it.

On the current 1.1.4 release and on the current master, tab completion for "~" is not working. Tested in both Cmder and vanilla, and on a clean VM.

I had tried to debug this to figure out what was happening, but LOG() and ERR() were not outputting any messages in the logs when I put them in rl_module.cpp, and I have no idea how to set this up in a debugger since it's a program that injects a dll into a running process. Just out of curiosity, how do you have this set up for debugging?

scoop info clink
show outdated old repository version

Name: clink                                                                                                                                                          
Description: Powerful Bash-style command line editing for cmd.exe                                                                                                    Version: 0.4.9                                                                                                                                                       
Website: https://mridgers.github.io/clink/
License: GPL-3.0-only (https://spdx.org/licenses/GPL-3.0-only.html)                                                                                                  Manifest: $USERPROFILE\scoop\buckets\main\bucket\clink.json                                                                                                                Installed: No
Binaries: clink.bat
Notes
-----
Run 'clink inject' to start clink on the current cmd
Run 'clink autorun install' to auto start clink                

Lua scripts from v0.4.8 will likely report errors when used with v1.0.0 and higher, because v1.0.0 and higher aren't compatible yet with v0.4.8 argmatcher and generator lua syntax.

I'm working on it.

Recent regression: completion gets stuck using old match list.

Repro:

1. Type text (e.g. b).
2. Invoke any completion command.
3. Change the input text (e.g. to c).
4. Invoke complete or possible-completions.

Expected: it should use matches for c.
Actual: it uses matches for b.

Description

I'm trying to bind Ctrl+Alt+u to clink-up-directory but for some reason, it's not working. This is quite annoying as it's probably the shortcut that I've been using most often.
I am currently using clink (1.1.18.f27b9d) with Cmder. I'll also give it a try using plain cmd.

Note: I previously used clink v0.4.9 with ConEmu (not through Cmder) and the autorun option configured. The shortcut was working as expected.

I have added the following line to %USERPROFILE\.inputrc:

set keymap emacs
"M-C-u":        clink-up-directory
"M-h":          clink-show-help

I've also tried A-C-u.

clink-show-help (A-h) prints the following:

...snip...
M-C-u       : clink-up-directory                      C-u         : unix-line-discard                       A-1         : digit-argument                          A-~         : tilde-expand
...snip...
C-PgUp      : clink-up-directory                      C-x,C-g     : abort                                   A-7         : digit-argument                          A-C-f       : clink-expand-doskey-alias
..snip...

This output looks a little wrong to me... though, I'm not that familiar with readline. I was expecting the shortcut from .inputrc to override the default one.
C-PgUp works but it required to remove a shortcut from ConEmu.
It may be that some shortcuts in ConEmu interfere with it but couldn't find anything related to it.

I wish you a happy new year, full of accomplishments.

BTW I think you did a really nice job with clink. I'm glad that someone had the initiative to continue and improve on this awesome project. Any idea what happened with the original author?

[Feature request]
I enjoy using your clink variant!

But... If I use the TAB key when navigation through my directories or files I only get a list of matching items, but can't select them by tabbing through the list:

It would be nice if additional TAB-strokes would select item by item from the list, so I can tab two or three times to select my item and only hit enter, like in zsh:

(image taken after typing cd nginx and tabbing two times)

(image taken after typing cd nginx and tabbing four times)

thanks a lot for your efforts with https://github.com/chrisant996/clink/releases/tag/v1.1.0.4b5991 ;)
i just create issue on this fork
for notify
mridgers/clink#544, still reproduce on your last release ;)

Filing this as a known issue for searching purposes.

The default theme in Oh-my-posh has some issues:

1. oh-my-posh is pretty slow.
2. It emits a large amount of unnecessary and redundant ANSI escape codes (this is pretty inefficient, but doesn't seem to create any visual or functional problem).
3. It ends the prompt string with an ANSI escape code to erase to the end of the line. This is incompatible with the Readline library (on any platform) and will cause portions of the input text to sometimes disappear unexpectedly.
4. It emits Xterm 24-bit color escape codes, which are only supported in Clink v1.1.15 and higher.

Points 1 through 3 are issues in oh-my-posh itself, and Clink can't do anything to compensate for those.

Because of point 1, I can't recommend using oh-my-posh with Clink even if point 3 got fixed.

Maybe consider using Starship or cmder-powerline-prompt for fancy prompt formatting with Clink.

For example, if you want to use Starship, you can use a Clink script something like the following. You may need to adjust it to specify configuration settings and etc,

Starship.lua

local custom_prompt = clink.promptfilter(5)
function custom_prompt:filter(prompt)
    local starship_command = "starship prompt"
    local p = io.popen(starship_command):read("*a")
    return p
end

Originally introduced by the fish shell, this shows most recent commands matching up to the current character, in a muted color.

My first question is whether something like this is even possible with Clink. It'd be very useful!

In case it is possible, here are some links for reference:

• Fish Documentation
• zsh-autosuggestions
• PowerShell's PSReadline
• Bash's line editor doesn't support it, but someone rewrote the line editor and added autosuggestions, along with a ton of other features - ble.sh

menu-complete gets stuck when a previous match dir and new match dir are the same length.

REPRO:

• For example, in the clink repo, where clink\lib\ and clink\lua\ both exist.
• Type dir cli,menu-complete,l,menu-complete,menu-complete,s,menu-complete.

EXPECTED: completion is clink\lua\scripts\.
ACTUAL: nothing happens, because clink\lib\s* doesn't exist ("lib\s*" is used by mistake instead of "lua\s*").

This regression was introduced in the v1.0.0 rewrite, as part of the match_pipeline stuff.

Split out from #13:

• doskey macros separated by a $T echoes the next cmdline
• doskey macros beggining with $T are not recognized as valid command (works in vanilla cmd.exe)

I cannot express enough how excited I am about this project being resurrected. HUGE respect to you, @chrisant996 for giving a new life to this awesome app. Keep up the good work!!!

Split out from #13:

• arrow keys don't exit reverse-search-history like in bash (need to press ctrl+j)

Yeah, there are issues right now with extended keys in search input mode (and other similar input modes).

The big picture issue is that Readline's key binding system allows gibberish to be input accidentally if you press an extended key that isn't bound to anything. I know that's how *nix terminals work, but I considered it unacceptable in the late 80's, and I still do. So I'm trying to make Clink's input system smarter -- if a particular extended key isn't bound, then Clink will avoid sending the key sequence through the terminal input. However, Readline has input modes where it isn't really using the key bindings in the first place, and I don't have the conditions quite right yet for which keys to suppress in those input modes.

Not sure if this is by design or not, but one thing about the clink 0.4.9 I found immensely convenient was the tab autocomplete auto-quoting that seemed to happen but appears missing in your v1.1.11.

For example, while using 0.4.9, typing

C:\Users\username> cd \program

Followed by the TAB key results in the following change:

C:\Users\username> cd "\Program

Note the inserting the opening quote symbol. This now allows you to type a space character and hit TAB again to reveal paths that match.

However, using your v1.1.11 and typing

C:\Users\username> cd \program

Followed by the TAB key doesn't quote and typing space also doesn't autofill paths with spaces.

In addition, using your version and typing

C:\Users\username> cd \program(space)fi

Followed by the TAB key doesn't autofill matching paths.

Am I missing something?

Go to root of C:, then type cd "pro and repeatedly invoke menu-complete: when it wraps around it gets confused about the quote and leaves an extra p: cd Ppro.

Importing from mridgers #398, originally posted by @dkiestra and @rivy

The simplest problematic command line is:

set /p = <NUL

This command string (a valid, working construct for CMD), causes CMD with clink to hang (with no response to CTRL-C. Constructs such as this are used to initialize files...

set /p = <NUL >FILE creates a 0 byte file, "FILE"
set /p =foo <NUL >FILE creates a 3-byte file, "FILE", containing only 'foo', without a newline

Of note, the alternative construct echo | set /p = >FILE does work correctly, without hanging, under CMD with clink.

Additionally, set /p VAR="" shows an incorrect prompt. It prints a shell prompt (from %PROMPT%), which is usually the current path followed by '>', e.g. "C:\Users>". It should print nothing. But, notably, set /p VAR="" does not hang; it correctly waits for a user input line and then sets VAR correctly.

Hey!

First of all I'd like to sincerely thank you for reviving this project and adding hundreds of improvements!

I was using the original repo's Clink until I discovered your fork yesterday. The new documentation is really comprehensive and helpful.

I used this repo called clink-completions along with Clink, but after upgrading to your Clink fork, the completion for Scoop seems to be broken.

Other completions are working fine as they did before upgrading (like git, npm, dotnet, choco etc.). I saw the following in your documentation

Script compatibility should be very good, but some scripts may still encounter problems. If you do encounter a compatibility problem you can look for an updated version of the script, update the script yourself, or visit the repo and open an issue describing details about the compatibility problem.

So I decided to open the issue here.

Once again thanks and cheers!

Seems that the vendor/clink.lua is no longer loaded starting with commit dcf44d6370e354237df15116117a85eb8b3cf18f.
I would just like to know if this was intended and the reasons behind it.

@daxgames (I assumed you're Cmder's maintainer based on contributions)
I think this could also be handled in Cmder by simply giving the file a different name (e.g. clink.lua → cmder_clink.lua).
Maybe you could sync with Cmder's maintainer regarding this to avoid future issues. With the version of clink that cmder is currently using this doesn't occur. I'm using the latest clink version 1.1.19.adf144 and noticed that the completions defined by Cmder are not working anymore.

Another option would probably be to have an exception for clink.lua if the parent dir is vendor but this sounds more like a hack.

Issue fixed with commit d073df557bf4a80a5949dde90da96f6c9ebbf997.

See: #4

The resulting binary has a hard-coded path from the GitHub build machine.
Need to track down why.

Hi there,

I use clink everyday at work. Thanks you for reviving it !
However, since scoop updated its version to your repo, clink doesn't display the CMD prompt anymore. It happens in either injected or in autorun.
Usual commands like DIR are still working except I don't have a prompt and Ctrl+L doesn't clear the CMD anymore. It is not the most practical for daily usage.
My version is 1.1.8.f031c7, running in plain Windows 7 CMD.

Could you get a look at it ?

Opening an issue for the motivation for PR #37.

@aavramch said:

Please allow doskey macros to override built-in handling of .. and -. Thank you <3

In vanilla CMD, tab completion for path works even after typing a switch, like here cd /d C:\Users\abc, where 'abc' gets completed to 'abcdef' on pressing TAB.

But when Clink has been injected, TAB doesn't do anything.

Is there a setting that needs to be configured for this?

Is there a way to initialize some variables, aliases (doskeys), much like .bashrc or .zshrc or PowerShell's profile in Clink? They should run/get initialized every time Clink is injected.

Thanks!

It seems that the new Lua API are incompatible with z.lua. For instance, it completely ignores "_ZL_ADD_ONCE" environment variable. I've tried, unsuccessfully, to modify the z.lua code and insert the new APIs definitions to the "initialize clink hooks" section, but I don't think I have enough Lua skills to make it properly work.

Thank you for your great work!

Split out from #13:

• alt+< n > followed by alt+ctrl+y isn't working

Versions 1.1.8 and 1.1.11 are detected as threats by Symantec.

thank you.

Hey! I tried following your documentation https://chrisant996.github.io/clink/clink.html#customisingtheprompt for a custom prompt, but it seems to be behaving weirdly. This is my prompt function

local custom_prompt = clink.promptfilter(50)
function custom_prompt:filter(prompt)
    local hello = io.popen("oh-my-posh"):read("*a")
    -- print(hello)
    return hello
end

OhMyPosh is a shell-agnostic prompt customizing utility.

The print statement (commented out in above function) works as intended, but when the same string is returned from the function, it messes up the formatting

Any idea how to resolve this?

Importing from mridgers #396, originally posted by @ticklemynausea:

I use Cmder and ConEmu and I've been unable to input unicode emoji characters into the console by pasting them. Both ConEmu and Cmder support these characters correctly: http://imgur.com/a/hqWKV

Steps to reproduce:

go to http://getemoji.com and copy a character that your console font supports. The top hat emoji 🎩 works fine with consolas font (don't copy this one, github replaces these with images)
paste it to a clink-enabled console. It will be pasted as two single byte unknown characters.
paste it to a console without Clink. It will be pasted correctly.

If it can, then it can default to disabling terminal emulation.

There doesn't seem to be a built in way in the Windows UI to enable VT processing in a specific console instance, only to turn ConsoleV2 on or off for all console instances (and ConsoleV2 controls more than just VT processing).

It would be useful and convenient to have a setting for Clink to enable VT processing in its console host.

Opening an issue for a change included in PR #37.

History lines are split on any control characters.
So if echo ^[[7m reverse video ^[[m is entered, it will show up as three separate history entries, split at the ^[ (ESC) characters.

Ideally the command would be shown as a single history entry, and ideally the history command would translate the control codes for readability rather than letting the terminal handle them.