Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build

news.softpedia.com

Post reply on HN
Print view View original

191–200 of 350 posts

Re: Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build

#191

Post by jeeva »

ygra wrote: post #93
cableshaft wrote: post #64

Earlier quoted context omitted.

I just wrote batch files that serve as aliases for those. I type ls in my command shell and it does a dir /w behind the scenes, which makes it look more like how it looks in Linux anyway. Here are the ones I have: * cat.bat: type %1 * clear.bat: cls * diff.bat: fc /n /w %1 %2 * ls.bat: dir /w %1% * pwd.bat: cd * touch.bat: echo . >> %1 * top.bat: tasklist All have an @echo off at the top too. Touch is a little janky,…

copy nul %1 >nul to get an empty file. It's not a replacement for touch, though, as touch will do something different to existing files. Your attempt will silently overwrite the file in that case.

Couldn't you just append null to a given filepath to get the same result, or am I misguidedly assuming that >> creates files that don't exist?

Re: Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build

#193

Post by gpvos »

nailer wrote: post #134
dvh wrote: post #27

Btw did anyone noticed that in windows 10 you can resize cmd.exe to more than 80 characters width! When I first saw it I almost cried.

Most Windows terminal people use ConEmu rather than the inbuilt terminal apps - it's like iTerm2 vs Terminal.app on MacOS. ConEmu adds Unix style cut and paste, tabs, etc. Add openssh, PSReadLine and PSCX and you've got a proper terminal setup. Also MS should really improve the inbuilt apps to do this stuff.

It has never been stable for me, so I stick with the console, even though I would like to switch to something better.

Re: Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build

#194

Post by melolife »

mauvehaus wrote: post #21

That's nice. Can you pipe binary data without powershell corrupting it, or is that now a feature? https://brianreiter.org/2010/01/29/powershells-object-pipeli...

I found out yesterday that `Select-String`, PowerShell's "grep equivalent" expands tab characters to spaces.

Re: Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build

#195

Post by yoz-y »

algorithmsRcool wrote: post #8
hugja wrote: post #4

I'm probably wrong, but can you not type "ps" into CMD and get the PowerShell prompt? If so, can you do it the other way around as well?

you can run "powershell" from a CMD prompt and "cmd" from a powershell prompt. You can also nest prompts to switch context between them.

You can also `start /b cmd` for some very interesting results. I still have not understood why this works this way.

Re: Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build

#196

Post by brazzledazzle »

gfody wrote: post #176
mauvehaus wrote: post #21

That's nice. Can you pipe binary data without powershell corrupting it, or is that now a feature? https://brianreiter.org/2010/01/29/powershells-object-pipeli...

Related, running something like decrypt hugefile.dat | encode outfile.dat will usually result in powershell using up all your system ram and crashing.

On a somewhat related note, one of PowerShell's biggest weaknesses is memory utilization. And since they make it so simple to pass around hefty object collections it tends to bite you in the ass early on. Particularly when you're using cmdlets. When doing real scripting that actually needs to be run as a job I am surprised when I can get away with cmdlets and don't need to manage .net APIs/objects directly. Especially third party cmdlets.

One performance tip I picked up early on: If you're passing around large object sets you need to operate on try to keep them in a pipeline. Populating a variable and interacting with it is arguably more readable and maintainable, especially for junior people, but it has a heavy cost in terms of memory.

That said every version of posh is better than the last so I may be wrong or overestimating the impact for the newest versions. YMMV, don't believe everything you read on the internet, etc.

Re: Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build

#197

Post by ergot »

Powershell is very insecure and is heavily abused by potential attackers as it's more flexible than CMD.exe. Of course, arguing about CMD.exe vs PS.exe is pointless, but it still needs to be argued.

There has been a recent spate of talks in Blackhat conf. and other confs, about the versatility of PS.exe, how it is used to perform persistence in comparably little characters, or lines of script than CMD.exe

Some of my Win10 deployments even contain a script which silently disables PS.exe in the installation, and removes every reference to that executable in the registry. There are a few cases where I caught PS.exe re-spawning itself when a Win10 update arrives, so a PS-free deployment is hard to enforce.

Re: Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build

#198

Post by tonyplee »

TorKlingberg wrote: post #104
cryptos wrote: post #44

It would be nice, if they would improve the terminal window a bit with tabs and the like (like Gnome Terminal for example).

Meanwhile, Gnome Terminal has been taking away the tabs...

Did they, why?

I have switch to xfce4-terminal for a while in all my system....

Re: Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build

#199

Post by ryao »

EE84M3i wrote: post #157
ryao wrote: post #83

Earlier quoted context omitted.

That is correct. Most people do not notice because the buildings in bash are almost completely equivalent to the standalone binaries.

I've only ever really noticed with 'time' and 'echo'

I have noticed this with echo too. In specific, the bash echo built in does not drop support for -n and -e when bash is forced into standards compliance mode as /bin/sh. That causes breakage on systems that use more strictly compliant shells when code was written against bash as sh under the assumption that either -n or -e work. I spotted a regression in Linus' tree a while back where this very thing happened in the build system for perf. Sadly, my patch to fix it was ignored:

http://www.gossamer-threads.com/lists/linux/kernel/2218440

Post reply on HN