>>21524 (OP) Honestly desu I wanted to like Powershell and it has some powerful features but it makes simple stuff too complicated.

>>21533 Well, there's aliases if you don't like typing things like Get-ChildItem or Invoke-WebRequest. You can make it look a bit like Bash for more simple tasks. For more complicated tasks though, it's basically "C#, but as a scripting language".

>>21535 I just looked up >how to use copy con in powershell and the answer was >you can't Quite disappointing. I think dir also behaves differently than in cmd. As a scripting language, it still looks a lot better than bash, but it's only used on windows so that's kinda meh.

Do I want to though?

>>21544 PowerShell isn't a superset of .bat. If you want to read from stdin, you can use Read-Host. >I think dir also behaves differently than in cmd Everything works differently in PowerShell than cmd or bash. Traditional shells are built around this idea that "everything is just strings". Pipes and redirects are used to take the string written from one program's stdout, and put it into the stdin of another. There are no data types in either language, only strings. Compared to that model, PowerShell is... basically just shell language syntax bolted on top of a .NET language. Every thing has an actual data type, and most commands you use are actually classes, and not executables external to the shell. These special commands are known as "cmdlets", and the output of them is an object, not a string. It's just that when you type the command into your terminal emulator, the end result is made into a string for you to view. The dir command is an alias for Get-ChildItem, which can do more than just enumerating the files in a directory (it can recursively enumerate them like the tree command too). Rather than returning a string, it's returning an array of objects whose type is System.IO.FileSystemInfo.DirectoryInfo. What's so useful about using an object instead of a string? You can take that output and put it into another command to sort/order and filter by its individual properties. >it's only used on windows so that's kinda meh It's fully capable of being used on other operating systems. It's just that it's most popular in Windows due to them kinda being forced to use it.

>>21552 Can you explain this like I'm retarded? (I am)

>>21554 You are expecting PowerShell to work like cmd, but more powerful. In reality it works like C# with ugly syntax.

>>21555 That makes sense kind of, I'm not that anon though I was just curious

>>21524 (OP) <install ubuntu chroot and dotnet on your phone to use powershell bad bait

>>21566 Is it bad bait if it worked?

>>21566 Can't run PowerShell without dotnet, period. The shell relies heavily on .NET reflection, and could not be compiled AOT to be run as a standalone native application. Using proot-distro is done because Termux's selection of packages is ass.

>>21580 >Attack on titan mentioned Fuck its weird enjoying tech but not knowing how to code, it's like going to a weird country and everyones speaking a funny language I don't understand

>>21587 That is "Ahead of Time". Programming languages have different models of execution, in order to interface with your CPU which understands only its own native instruction set. The slowest method would be "interpreted". This would be where an interpreter program reads the source code in plain text, converts it into an intermediary format that can be efficiently evaluated, and then the interpreter program performs some sequence of instructions based on that intermediary format. This model tends to be preferred by more dynamic programming languages that need to be able to change things about their type system at runtime. The fastest execution model (typically) is ahead of time, native compilation. This is where a compiler program reads your source code and converts it to native machine code, writing the output to a file known as an executable. Aside from some optional debugging information, this executable tends to not have certain language-level information remaining in it. It's just a series of data and code sections that your CPU can very efficiently interact with. In between the two approaches are those that deal with bytecode and "just in time" compilation, typically involving complex language runtimes designed to synthesize the best features of both models. The Java Virtual Machine (JVM) and the .NET Common Language Runtime (CLR) are models that do this. Programs tend to first be compiled ahead of time (or sometimes dynamically) to an intermediary "bytecode" representation that retains language-level information, allowing for programs to mutate properties of their own data types and functions in a process known as "reflection" (for PowerShell, this is needed to be able to, while the program is running, load an external library containing different data types). That bytecode can then be recompiled efficiently at runtime into native machine instructions. In rare instances, this can even be faster than native execution due to the VM being able to profile your program for sections of code that are more and less frequently executed.

>>21599 Oh that makes sense, I have a few programs that are just written in "machine code" so does that mean they're written without a compiler at all? You don't have to answer this because spoonfeeding is bad for the record, I just found that interesting

>>21580 Anything that can't be compiled into a standalone is garbage

>>21602 Typically, when people say programs are written in machine code, what they mean is "assembly". Basically, these are mnemonics that map one to one to actual machine code instructions.

>>21605 Why doesn't everyone just learn assembly then, wouldn't that be the best language and put and end to the rustdev phenomenon?

>>21606 Few reasons... 1. Assembly language is the least portable way to write programs. Different CPUs have different instruction sets, and every instruction set has its own assembly language. If I wrote a program for a desktop computer, I would have to rewrite 100% of the source code to then port it to your phone. Writing for different operating systems on the same CPU also causes problems, because operating systems have different ways to interface with their kernel. 2. There is no such thing as "data types" in assembly. This makes abstraction difficult. 3. Operations that could be expressed in maybe one line of code in a high level language may take many lines of assembly. For instance, even making a function call requires saving certain registers onto the stack, loading the parameters to the function call into registers, and then executing the call instruction. Each of these is a different instruction, written on a different line. 4. It is much easier to make mistakes in assembly, and the supply of programmers capable of competently writing assembly programs is far exceeded by the actual demand for software. Also, Rust exists because people felt there was a need for a good, ahead of time compiled language that simultaneously allowed for certain low level operations while also making it difficult to make mistakes. Switching to assembly would not fix that problem. You would just have all of the problems with programming in C, amplified. To put an end to Rust development, make a language that solves these problems better than Rust.

>>21580 <you can use <this useless shit that is worse than every other option> on your phone if you bloat it with a needles full OS package and some M$ backdoor goodness >bad bait <actually the M$ backdoor goodness is a strict requirement

>>21610 Thank you for your crash course in programming fundamentals anon, I appreciate you, normally I don't understand this stuff but today I did, I'm going to save your posts to read again later

>>21611 <M$ backdoor Do you also like to refer to the JVM as an Oracle backdoor?

>>21615 1, non-tards use openjdk which has nothing to do with oracle. this shift started even before oracle bought sun. oracle didn't actually create java you know. 2. M$ love spying on their users. they sometimes don't even try to hide it.so M$ backdoor was meant literally, because that's literally what you get. a dotnet-specific example for your amusement: https://github.com/dotnet/sdk/issues/6145

>>21524 (OP) >prööt-distro

>>21684 E/B/IN:DD:DDD

Why use powershell when I can use tcsh on my phone as god intended.

>>21684 I've found it's a lot nicer than using vanilla Termux. There's a lot more packages, and you can also have multiple distros installed if you want to avoid package conflicts for different projects.