Hello.. I'm new to Yori.. I'm enjoying its simplicity, useful completions, and (thank you for) the aliases. But I do have some pretty basic issues:

1. Is there a way to use ERRORLEVEL within an IF statement?..

And:

2. Is there a way to determine from a .ys1 script (Init file) if the current shell is running with elevation?

I usually do this in CMD by running any command that requires elevation, which sets the ErrorLevel.. for example:

$ net session>nul 2>&1 $ if ErrorLevel == 0 (Echo We have elevation)

But in a Yori script (Init file) it seems neither if statements, nor the ErrorLevel can be used (conditionally) at all.. Even calling an external script .cmd for this task seems not to work.. Or is there currently a way to do it?

In Yori environment all works perfectly:

YORI> ECHO -n -- -argument1 "value 1" --> -argument1 value 1 this is not what we want but quite expected. Here we need to escape our " symbols

YORI> ECHO -n -- -argument1 ^"value 1^" -- > -argument1 "value 1" and all is nice and flawless...

But something weird is going on when I try to use yecho.exe with CMD: CMD> yecho.exe -n -- -argument1 "value 1" --> -argument1 value 1 Nothing special... all as expected

CMD> yecho.exe -n -- -argument1 ^"value 1^" --> -argument1 value 1 Ok... the thing here is CMD by itself handled ^" symbols and yecho.exe recieved -argument1 "value 1" as in previous attempt and nothing suprisingly new here... so in theory we just need to add additional escape for ^ symbol:

CMD> yecho.exe -n -- -argument1 ^^^"value 1^^^" --> -argument1 ^"value 1^" And that is completely unxpected behavior... let's even try what is not supposed to be:

CMD> yecho.exe -n -- -argument1 ^^"value 1^^" --> -argument1 ^"value 1^^" And I have tried a lot of things to make yecho.exe work with CMD and double quotes, but nothing was successful... the only thing what's worked is such construction:

CMD> yori.exe -nouser -c ECHO -n -- -argument1 ^^^"value 1^^^" --> -argument1 "value 1" And this is quite expected and absolutely normal...

I understand that this is quite a headache with all that double quote "magic" in Windows and CMD specially and do not expect a quick reaction... Just want to ask: Am I missing something here? Maybe you can give an advice how to properly escape the double quotes so yecho.exe will work with CMD as it works in YORI?

http://malsmith.net/download?obj=yori/latest-stable/win32/ysetup.exe

cant be extracted with InnoExtract or 7-Zip in a meaningful way.

It would be better to have this, or to simply offer a zip build with the executable.

I've jumped on the Yori train and enjoy it :) context and version:

• I use it from within Windows Terminal (latest 0.10.781 with mouse support).
• yori 1.21

issue: What I cannot get to work is "ctrl click select", which works fine when yori is started from a simple CMD terminal.

solution approaches:

• I've set YORIQUICKEDIT=1 which don't have an effect.
• As well I've checked issue #19 and updated ypm -u (which fixed the #19 issue, but not mine)

request:

• does one have a solution for this, or is this another problem with WinTerm compatiibility?

Hi, am a heavy user of skipping words on the command line via the Ctrl+left and Ctrl+right hotkeys.

Bash/fish and cmd.exe and GUI textareas support it, although they differ slightly on the right arrow. The Unix shells go to the end of the word (rather than beginning of next) when moving to the right. Probably to be able to edit the end of the word more quickly. I don't have a strong preference here.

Hopefully Yori could support it as well.

Hi!

Another finding... let's create C:\temp\raiser.txt and lock it with following:

CMD> notepad.exe > "C:\temp\raiser.txt"

so this file will be locked until notepad.exe will be closed... and now try to move or erase this file:

CMD> "ymove.exe" "C:\temp\raiser.txt" "C:\temp\deraiser.txt"
CMD> ECHO.!ERRORLEVEL!
0

ymove.exe "C:\temp" "C:\tempNew" with locked file in C:\temp leads to the same... and almost same thing with ERASE:

CMD> "yerase.exe" "C:\temp\raiser.txt"
erase: delete of \\?\C:\temp\raiser.txt failed: <<here goes localized error message>>
CMD> ECHO.!ERRORLEVEL!
0

at least error message is shown, but ERRORLEVEL becomes 0

Hello!

I understand everything has it's limits and not insist to get this into primary goal... this is just a remark!

I am seeing a sharp drop in performance using decent amount of stream input and output.

This is only for example but let's assume we have a text file with such content: replace.txt

0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

So in real life we have a text file encoded with non-english ASCII symbols.

And we need to replace all those 36 values with text and going to do so with following script with a lot of pipes: replace.ys1

ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "0" "-" | REPL -- "1" "-" | REPL -- "2" "-" | REPL -- "3" "-" | REPL -- "4" "-" | REPL -- "5" "-" | REPL -- "6" "-" | REPL -- "7" "-" | REPL -- "8" "-" | REPL -- "9" "-" | REPL -- "A" "-" | REPL -- "B" "-" | REPL -- "C" "-" | REPL -- "D" "-" | REPL -- "E" "-" | REPL -- "F" "-" | REPL -- "G" "-" | REPL -- "H" "-" | REPL -- "I" "-" | REPL -- "J" "-" | REPL -- "K" "-" | REPL -- "L" "-" | REPL -- "M" "-" | REPL -- "N" "-" | REPL -- "O" "-" | REPL -- "P" "-" | REPL -- "Q" "-" | REPL -- "R" "-" | REPL -- "S" "-" | REPL -- "T" "-" | REPL -- "U" "-" | REPL -- "V" "-" | REPL -- "W" "-" | REPL -- "X" "-" | REPL -- "Y" "-" | REPL -- "Z" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"

All works... but: `timethis.exe yori -nouser -c YS "replace.ys1"

Elapsed time:      0:00:11.989
Child CPU time:    0:00:00.156
Child kernel time: 0:00:00.156
Child user time:   0:00:00.000
Tree CPU time:     0:00:00.562
Tree kernel time:  0:00:00.406
Tree user time:    0:00:00.156

12 seconds certainly not a big deal but if process comes to real text file with normal contents speed degrades drastically...

The thing here is if we split those 36 REPL pipes into 36 different lines:

ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "0" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "1" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "2" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "3" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "4" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "5" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "6" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "7" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "8" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "9" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "A" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "B" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "C" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "D" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "E" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "F" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "G" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "H" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "I" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "J" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "K" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "L" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "M" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "N" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "O" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "P" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "Q" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "R" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "S" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "T" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "U" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "V" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "W" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "X" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "Y" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"
ICONV -i ascii -e utf8 -w -- "replace.txt" | REPL -- "Z" "-" | ICONV -i utf8 -e ascii -w | SPONGE -- "replace.txt"

and do that again with: `timethis.exe yori -nouser -c YS "replace.ys1"

Elapsed time:      0:00:01.738
Child CPU time:    0:00:00.436
Child kernel time: 0:00:00.421
Child user time:   0:00:00.015
Tree CPU time:     0:00:02.281
Tree kernel time:  0:00:01.656
Tree user time:    0:00:00.625

So despite there was 36 disk reads 72 encoding conversions and 36 disk writes it is 6 times faster than 1st variant... one problem here is we need to check an ERRORLEVEL after each of 36 lines to ensure that all was correctly.

And by the way in real life with 30 lines in script we get speed something around 5 seconds per file and with one line in script with 30 pipes speed drops to 30 seconds per file!

And this is not about REPL only... I've tried a lot of sequiental pipes around multipe ICONV and it seems it degrades in the same way!

So it is basically 6 times faster everywhere I've seen, tried this with CMD YORI YORIMIN and ONEYORI... and the numbers always almost the same!

And just for example tried this in CMD with external findstr.exe:

CMD> echo "long long long long long long long long long long long long long long long long long long long text"  | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text" | findstr "text"

So there is 128 pipes and nothing seems to degrade significantly... I am basically want to say that as I see this is not due to Windows piping mechanism!

Or maybe you can advice how to speed things up?

P.S. I'm so sorry to be so annoying =) I believe I am doing useful things for this project

ysetup and the update cab are being detected as trojan by several engines, so is being blocked by my corporate anti-virus (cisco amp and malwarebyte).

https://www.virustotal.com/gui/file/568d3e98510528d8fa1db59a0c21963933d0b7719610d623bbdad34098ad6956/detection

Would be nice to implement hot keys to exit the shell as POSIX shells do. Traditionally it is ^D, though Windows used ^Z+Enter instead.

However since WSL has become more common implementing both might be a good idea. Thanks.

The Ctrl-Left functionality to move the cursor between words also expands environment variables and trims spaces. However, it doesn't actually re-render the command line immediately, so the mutations only show up after a subsequent editing command.

This can lead to some confusing and undesirable behavior, as seen in this video, where I use Ctrl-Left to jump past an environment variable and then press Del to delete the first character (which should be %):

Maybe I missing something but can I do hex output to file with any Yori utility?

It will be nice to do something like this: echo -hex -- \x04\xFF > C:\temp\file.hex or hexwrite \x04\xFF > C:\temp\file.hex

Maybe I am wrong but I think this very simple to implement, so things like described in this question can be done in Windows.

By the way I've noticed that REPL utility is missing from main HELP command of Yori shell... it was very nice to find it by accident =)

I wanted to first thanks you for your amazing work. on this project.

In the WIN32 API we are limited to MAX_PATH for the current directory. Yori for now uses the SetCurrentDirectory() function in its implementation of the YoriLibSetCurrentDirectory() when calling chdir.

So when I try to chdir to a very long path name I get the The filename or extension is too long. error

I was wondering if Yori could instead simulate a pseudo current directory (issuing a warning maybe), so that file manipulation would behave more transparently. When you would call any internal command, Yori would expend the full path name with the \\?\ prefix to the command. This way it would be more convenient to work on a set of files that are nested deeply. As long as the commands you use are long path aware.

Of course all the Yori commands are already long path aware, so it would not require extra work for them.

There would still be a problem when calling an external command because there is no way Yori could know for sure if a parameter is supposed to be a filename. So people will have to Use Ctrl+Tab, but it would be fine in my opinion.

There is also the option to use the short path name if available when path is too long for SetCurrentDirectory(). So people would not have to type the short path manually. This would push up quite a lot the depth at which you can normally work.

Of course you are more qualified than me to determine what the best option would be. I guess using short path name could also lead to other drawbacks.

EDIT: I am using the latest Yori 1.80 release under Windows Server 2003.

For example, there exists a directory "MCNP格式转换工具" in the Desktop directory, and the PWD is Desktop. If I typed "cd MC" and press TAB to autocomplete the residual characters, the display result looks weird.

I guess the behavior of yori is to display characters based on the same width (1 ASCII character width) but the Chinese characters occupied 2 widths.

Wish this bug could be fixed in the next update 😄

Hi!

There is a high chance that I just didn't manage to find the relevant documentation/discussion, but I can't figure out if yori supports reverse search (like ctrl+r in bash or in clink). Any help is appreciated. Thanks!

Clink offers the ability to customize its shell completion with lua scripts. Some of clink's own functionality, like built-in completions, are also implemented in lua. This integration is very powerful; it makes it possible to customize the built-in completion as well as add custom completion logic.

In addition to the abilities of the lua programming language, Clink offers a parsing API that greatly simplifies the development of custom completion scripts.

This is related to our discussion in #41: supporting lua and Clink's argument parser API is one way to address the concern about the complexity of completion scripts for non-trivial commands like git.

Another benefit I can see is that by supporting this API, existing lua completion scripts can be used as is in yori, which may make the idea of migrating to yori much more attractive for clink users. Published collections of clink completion scripts like https://github.com/vladimir-kotikov/clink-completions would instantly add to yori's power and hopefully foster community enthusiasm and engagement, since the clink project itself appears to be abandoned.

TBD:

• The clink parser API does not have support for descriptions, so it may need to be extended to implement feature requests like #42
• Clink functionality can be accessed in lua completion scripts via the clink variable. I imagine that you would want to expose a yori variable instead (but expose clink as an alias for compatibility with clink scripts)

I know there are already requests for Scoop and Chocolatey, but consider making Yori available in WinGet. This seems like a good candidate for the fledgling package management system.