281–290 of 298 posts
Earlier quoted context omitted.
I just have to say, that's a beautiful name for a shell.
Thank you. I found choosing a name for the shell harder than writing any of the code
I checked out Oil previously which looks nice but more of an incremental improvement over Fish/ZSH rather than a significant evolution (it may have changed since then, this was last year). Im most excited about Elvish shell and the language that's being developed around it. The shell is built with Go and feels super fast compared to my plugin-heavy ZSH. The language design is quite nice too but still very alpha. Look…
FWIW, OSH is the incremental improvement, and Oil is the new language (explained in the intro to this post.)
Earlier quoted context omitted.
Please note that copying and pasting commands from a web browser into a terminal can result in malicious code being executed. A good idea to double check using a text editor. http://thejh.net/misc/website-terminal-copy-paste
Sounds like sandboxing of pasted code until confirmation would be a good feature for a new shell ...
Earlier quoted context omitted.
I remember a few years ago poking at julia and thinking it would make a really good shell language. The thing that killed it for this use at the time was slow startup; is that better now?
Much better, it's certainly worth giving it another go. It's still much slower than Python, but it's quick enough that I don't notice it all. $ time julia -e 'println("Hi")' Hi real 0m0.241s user 0m0.216s sys 0m0.196s $ time python3 -c 'print("Hi")' Hi real 0m0.046s user 0m0.020s sys 0m0.000s
Earlier quoted context omitted.
Well, POSIX is pretty similar to what I mean, but it has a lot of low level stuff and I doubt that Microsoft has any ambitions to transform Windows into a POSIX compatible OS. I thought more about a higher level standard like adding Python, Lua or Qt to every installation by default. As some of those things are pretty heavy I doubt that it would be a wise choice to include them in POSIX. Just imagine a world were you…
Isn't that what electron is popular for?
But everybody who has build an electron app and a Qt/GTK app, will agree that the tool kits which are available to electron apps are not as sophisticated as Qt/GTK (not talking about the ton of downsides of electron apps (huge app size, outdated versions, etc.)).
I am completely pro PWA, but as far as I can see it it will take a few more years (at least) before we will get to a state which will allow us to use them in the same way we develop and use normal desktop apps nowadays.
I see that this person has opted not to use python 3 because it is 'less-suited to shell-like problems' than python 2. In an effort to understand the reasons for actively choosing against 3, does anyone know what problems those would be?
The few times I tried to de shell like things in Python, the absolute pain of actually running commands and getting to their output might be part of the reason. What is A=$(cmd) in bash is an absolute pain in python.
A = !cmd
Earlier quoted context omitted.
> I quite seriously believe that a 1000 line shell script only exists out of error. Perhaps the best use case for Oil is to provide a debugging environment where you can figure out what your legacy shell scripts are doing, and rewrite them in another language. > Unlearning bash-isms is not a liberty I can afford, as I need to be proficient when I SSH into a machine I do not own or control. This is a slippery slope. I…
> "don't make your own custom aliases / shell functions, because they won't be available when you SSH to another machine." If you're logging into a machine to the point you're editing files or require your customizations in this day and age you're doing it wrong IMHO.
Earlier quoted context omitted.
If I was ever to be religious, I would believe that PHP was the work of the devil. It's just so... uuuugh. It doesn't make sense. Did you know that you can increment a string in PHP? Yup. Of course you can't decrement it, that's crazy talk. Anyway, I usually avoid perl. While definitely a true programming language, I really don't like it. I find that it lacks clarity, and quickly collapses into bash-like hackery. I p…
It sounds like the original build script was poorly written. Bad (or hurried) programmers write bad code no matter the language. Are you claiming that its size was because Perl forced it to be long winded?
I feel like some programming languages, no matter the structure of the application, feels unstructured and write-only in nature. To me, Perl is one of such languages. Python has a similar effect, but I feel like it is more controllable as long as the project is kept within a sensible length.
So while that abomination was primarily the fault of the designer, I do think that Perl invites this behavior one way or another.
(I gave up entirely on reading that disaster of a build script, and instead instrumented system() so that I could trace the calls to various tools and infer the logic myself.)
In your FAQ you decry Perl as having no ability to redirect around other programs. Yet you don't explain how any of the following fail to meet those needs.: * http://perldoc.perl.org/functions/open.html * http://perldoc.perl.org/IPC/Open2.html * http://perldoc.perl.org/IPC/Open3.html * http://search.cpan.org/~odc/IPC-Open2-Simple-0.01/lib/IPC/Op... * http://search.cpan.org/~exodist/Child-0.013/lib/Child.pm * http://s…
Can you show me some code? How do you write this in Perl? f() { echo -- ls / echo -- } f > out.txt f | wc -l
#!/usr/bin/perl -w
use strict;
use English;
use autodie;
$OFS=$ORS="\n";
sub f { my $h ; opendir($h,$_[0]) ; print "--",(readdir($h)),"--"; closedir($h);}
my $out;
open($out,">/tmp/out.txt") ; select $out ; f("/tmp");close($out);
open($out,"| wc -l ") ; select $out ; f("/tmp"); close($out);
select STDOUT;
@ary=split("\n",`ls`);
around if you feel so inclined.