Closed MattiasFestin closed 6 years ago
i really cant understand why so important thing doesnot fix. WSL must help linux users and administrators to work in the windows wokspace. @iamakulov said ctrl+c is a good way cause he frequently switch between powershell and bash , so, i freqently switch between linux console and wsl. Changing mind from shift+insert to ctrl+c every time, makes me crazy, this ticket opened more than one year, its just ticket about fix control characters. But the greatest injustice is that in cmd shift+insert works!
If you'r using Git-Bash and the 'MINGW64' terminal emulator I found out that you can enable the linux terminal shortcuts like CTR+Shift+C/V:
@pinich Any idea for ctrl + u
or ctrl + w
cut word to windows clipboard ?
@avonar "I really cant understand why so important thing doesnot fix."
Appreciate your feedback. We're just as frustrated as you - this issue affects us all day long too!
However, we're a small team with a long prioritized backlog, but this item has been lower priority than some other critical work during the last several release cycles. However, we're hopeful that you won't have to wait much longer to see this ask make it above the 'cut' line ;)
Bear with us.
oh, and i thought i was doing something wrong... i found an not idea workaround: configure bash.exe to be a terminal inside vscode. Then i found ctrl+v to work well and it also gets better colours out of the box. Ofc it is not ideal if you don't use vscode, but might save your some time if you have it installed.
@DarthSpock Appreciate your analysis of how difficult it is (or is not) to modify the Console and/or WSL codebase. Sorry you think we're not putting much effort into our work, but I can attest from the insanely long hours the entire team has been pouring into these products over the last 3+ years, that you couldn't be further from the truth.
Fact remains that this feature hasn't been prioritized higher because there is an acceptible work-around (right click mouse/trackpad), and because we've had a MOUNTAIN of important, stretegic and tactical work that was of MUCH higher priority for many solid reasons.
We really do appreciate everyone's passion and enthusiasm - it literally fuels us every day - and we greatly appreciate your patience while we overhaul and modify a 30+ year old old, very fragile, utterly critical code-base. We're nearing the point where we can start delivering exciting UX features again - please bear with us just a little longer.
@bitcrazed Hey! I wanted to say you folks thank you for working on WSL and console and doing your job. Seriously, WSL is an amazing piece of work I love using every day.
It might be easy to lose enthusiasm when your job is criticized so often. I just wanted to remind that many-many more users donβt say anything because they like using your product and donβt have any issues with it. (And they like it because you did your job great.)
β€
Many thanks @iamakulov - I and the entire team appreciate your (and everyone else's) support :) We LITERALLY couldn't have made WSL & Console as good as they are today without all the support, bugs, and feedback. And we've still got a lot to do yet, so please do keep the feedback coming!
We much prefer to know what you need us to build, and/or how something should work, not how we should implement it. The latter requires a comprehensive understanding of many factors which few outside the team fully grasp, including:
Heck, it's hard enough for those inside the team to figure much of this out ;)
So, please do keep the feedback coming, continue to work with us & help us define, build, and deliver a WSL & Console that meets all our needs and gives us the crazy-powerful platform we all want so very much π
upvote.
There is a way to paste into WSL console using only keyboard, procedure is as follows: Requirement: needs to be only ONE WSL window open (at least in combined taskbar buttons)
@n3rd4i Sadly, the Shift + F10 doesn't work in Powershell window. If there would be another binding for that, this would be a viable approach, although I am not sure you have mentioned Win+T, that's unrelated :)
@FredyC It works for me - the Win+T
cycles focus through the task bar mini-windows (or whatever you call them) - those windows accept Shift+F10
. It opens the little shortcut window thingy that Alt+Space
normally does (or right-clicking the top left corner of the window).
BTW, It would be a usable workaround if Alt+Space
could optionally be configured to actually get processed normally. I would guess some action had to be taken to supersede the usual Windows handling of that. If so, seems like a registry key hack could make it skip that action.
Ah, I see now, that works indeed, but honestly, it might be just faster to grab that mouse and click instead of cycling through all windows with Win+T :)
It seems you don't even need to click on corner icon, right clicking on titlebar works and then you just hit E + P
and done. Definitely easier :) Only wish it would be some other letters as to hit P
I have to move away from mouse ... oh well.
"might be faster to grab that mouse..." Oh right! That's a great workaround - I suggest closing the issue. :trollface:
I found another solution. I bought a MacBook Pro. I'm not going to wait around for months/years for Microsoft to make WSL actually useful. Basic things like copy/paste, really?
MacOS terminal is far better than WSL. File permissions aren't all screwed up by NTFS either.
I've been making excuses for Windows for most of my life. I'm done.
Use Gnome, or get a Mac.
On Thu, Mar 15, 2018, 10:17 AM Jesse Connell notifications@github.com wrote:
"might be faster to grab that mouse..." Oh right! That's a great workaround - I suggest closing the issue. [image: :trollface:]
β You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Microsoft/WSL/issues/235#issuecomment-373455046, or mute the thread https://github.com/notifications/unsubscribe-auth/AB4-AmaBaOXddeC0Z3NGkSOEche--EMHks5teqIxgaJpZM4IMCMC .
Hi, three months ago I posted a zip file with scripts for a workaround on ctrl+v and ctrl+shift+v on console, they are really easy to use and honestly they are the more easy workaround I found, thanks again to @sgoranson and @loxal who share how to do this before me.
@echo off
SET bashPaste=your path to exe here
rem add on start
@reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run" /t REG_SZ /v "bash paste" /d "\"%bashPaste%\"" /f
pause
@echo off
rem remove
@reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run" /v "bash paste" /f
pause
I know that is annoying to not have it natively yet, but I'm sure there is a good reason behind it, I share the sentiment of @xdfil if you are a hardcore DevOps or a Pentester, they are a lot of important things that are not implemented yet, but for others who work on back ends like rails for example or many many others fields, this is a game changer, my life has been a lot easier for the past 2 years (06-2016 I believe), when pretty much all I need it was working as expected, been able to not have to jump between OS's is priceless for me, sincerely. Nowadays, I love my console, It could be better?, sure, but every patch I found something new to take advantage and hopefully soon, everything would work and I will be able to hack my neighbor with aircrack.
My current console after some tweaks
No need for people to get salty, a little patience goes a long way:
Just checked it in. See y'all in skip-ahead.
Before people ask, there is a plan in play for more customizable and configurable keyboard shortcuts, but that's more than a release away from here. This is a stopgap until we can complete that work.
Nice but when can we expect this feature in the Windows release? Many people got salty because this most basic feature is supported in macOS since a decade whereas Windows took "a bit" longer. Legacy should not be an excuse. I suppose that macOS had to solve similar problems and legacy implementations can be always resolved with explicit opt-in implementations.
The next full release of Windows with this enabled will be whatever comes after Spring Creator's Update (2Fall2Creators Update?).
@loxal & @all
We understand the frustration - we feel it all day too because, unsurprisingly, we all live in the Console all day long.
However, simple physics have prevented this feature from bubbling high-enough up our prioritized bug list to receive attention until recently: Console has a small team of 3 who've been working at breakneck speed to add the MANY feature improvements you've all seen over the last 2+ years, adding masses of VT support, 24-bit color, etc. while re-engineering & modernizing a complex 30+ year old code-base.
Legacy may not be an excuse in your mind, but it's a reality that's unavoidable. If we "break" the Console's existing Windows behaviors, we hear from 1000x more users than if we "break" a Linux user's workflow.
So, understand if there's an issue that appears to be "simple to fix" and it hasn't been, then it's safe to assume that there's a very good reason it's not yet been fixed, frustrating though the delays may be at times.
We greatly appreciate everyone's continued patience and continued feedback & encourage y'all to keep it coming: It helps us find & fix the issues that matter in a sane prioritized order.
"Legacy should not be an excuse"
@loxal That's actually a pretty damn good excuse in my book. A small team trying to modernize 30+ years of legacy code is a massive undertaking. I wouldn't wish it upon my worst enemy lol
Just think of how many global enterprise users of windows there are. Breaking compatibility in something so foundational as the console framework would be an SLA nightmare.
It's a lot to ask from all of us, but patience is key here. I think we're just all glad to see bash make its way into windows in the first place; look at how far we've come in 2 years!
All that said, @bitcrazed: do you see the Console team getting more resources any time soon or are you guys at optimal stride with 3 people?
do you see the Console team getting more resources any time soon or are you guys at optimal stride with 3 people?
@kavdev I don't think resource allocation is really something any of us on the Console team are at the pay scale to discuss. I think we'd all love to have more resources, more devs, to be able to churn out more features. Obviously, though - we're all on this team because of how passionate we are about it so of course we want more resources to be able to deliver more features.
It probably doesn't help that we keep rocking it with only 3 devs - what other team has that kind of feature/dev ratio? π
Idea here: Open-source the console. If Microsoft doesn't want to hire more console devs, then get devs to do it for free! Pretty sure there's been enough enthusiasm gone around to get a bit of help. Of course to avoid legal hassle, they'd probably have to reduce the cost of the OS by X amount since they probably wouldn't want to compensate anyone for their service to a product that they sell that uses the work. Probably still much more complex than that but they've open-sourced Powershell and there's VS Code..plus you've got the ColorTool which is open-source. I would think it's less of a stretch to open-source the console than it is to open-source WSL or especially Windows (as great as that would be) but who knows? Maybe it IS a big stretch in MS's mind.
@DarthSpock Open-sourcing the console is something we discuss regularly. While it's not on the cards in the near term, it's not entirely out of the realm of possibility. One of the biggest challenges, however, is that the Console is FARRRRR from being in a useful shape for others to rapidly comprehend and contribute to in a meaningful way. Even internally!!
As @zadjii-msft points out above - we'd love to have "some more dev resources" on the team, but at the same time, be they full-time employees or community contributors, additional resources will decrease productivity of an established team - a team who've spent the last 3 years unpicking and understanding, and mastering every corner of a large, old, messy, confusing, but utterly essential code-base.
And as @zadjii-msft points out - though it may not be apparent from the outside - the 3 devs we have keep overachieving in every release. Maybe if they struggled and complained more, we might get more resources.
We'll bear that strategy in mind for the future ;)
@kavdev - many thanks :)
We're excited to come into work to improve the Console in tiny/unmeasurable, huge/significant ways each and every day. We're all passionate command-line nerds and do this work because we believe Windows users (including us) deserve a kick-a$$ command-line experience. We'll get there - just stick with us while we wrestle this beast into shape :)
It must be a really amazing experience to be on such team, sounds like a well-oiled machine so to speak. Keep up great work!
Ohh yeahh! You are awesome!
Although I will wait patiently for this feature to arrive, I have to say that I can not wait for it to arrive on my box :)
Until then I like to use the console from within Visual Code as a work around for getting ctrl-v/c working.
Am 3/20/2018 um 11:42 PM schrieb Mike Griese:
No need for people to get salty, a little patience goes a long way:
image https://user-images.githubusercontent.com/18356694/37686443-b84ab622-2c54-11e8-924b-b885748e28c1.png
Just checked it in. See y'all in skip-ahead.
β You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Microsoft/WSL/issues/235#issuecomment-374782051, or mute the thread https://github.com/notifications/unsubscribe-auth/ADAMVp9zy9JgEW7Pca7CaYb8yXZmmCkcks5tgYXEgaJpZM4IMCMC.
@FredyC & @renzok - It is genuinely humbling to work with the awesome WSL and Console engineering teams, and with so many of you in the community. I've learned SO MUCH in the last couple of years and continue to do so daily.
We're like swans - we appear calm and collected up-top, but are paddling like fury underneath π
Excited (relieved?) to finally be able to announce that this issue is now fixed (by @zadjii-msft)! Copy and Paste arrives for Linux/WSL Consoles
Marked as fixed in insiders build 17643. Will ship in Win10 18H2 release.
Closing since the work is now done.
That's a great news! Thanks for all the hard work! π
I don't know if this is fixed. I have 1903 and in my Ubuntu bash, CTRL+SHIFT+C/V works, but within WSL for VS Code, it does not.
It would be nice to have keyboard shortcut for pasting into console instead of right clicking (Or window menu -> edit -> paste).
I tend to use my keyboard as much as possible. So it would be nice to have a shortcut like git bash: