41–50 of 110 posts
Anyway, glad to see this. I'll be sure to recommend it to whomever I'm preaching.
What do people think about wrapping a Natural Language Processing interface around the command line (for educational purposes)? For example: "Show me all of my files, including my hidden ones" --> "ls -a". Good idea or not?
Whether you'd get any users is another question.
You might also consider what a command-line interface based on Dasher would look like. Probably not just a simple typing interface. You could extract a great deal of useful information from completion mechanisms, for instance.
Earlier quoted context omitted.
We teach things like bash by assigning each user to a virtualized Linux server. That gets really expensive and hard to manage when you give one to every anonymous user who hits the site (especially when our courses pop up on sites like HN). With that said, I have been wanting to change the UI to be less intrusive, so you can better see what you're signing up for.
Seems like a good use-case for docker
Lately I've been butting heads with some seriously anti-command line people. I'm not sure if this is a growing sentiment, or I'm just advocating CLI usage more as time goes on. Anyway, glad to see this. I'll be sure to recommend it to whomever I'm preaching.
Or I could open up my GUI, click "work" from my side nav selections and navigate through 2015/08/24/important/ and click my file to open it. I can even open two directories and ^x^v into another directory. Or drag/drop to move. Rather than "mv file.txt ../../25/file.txt"
I think it's important to show the more "cool" stuff you can do from CLI. Once you have them interested, explain the building blocks for how they can get there.
Explaining the building blocks to someone who doesn't see the benefits of the CLI will have them thinking about trivial problems and wonder why anyone would ever choose to use the CLI when the GUI is so much faster/easier/less memorization. When I was taught pwd/ls/cp/mv all I could ask myself is "....why? GUI is faster/easier/less memorization/no typos wasting time".
[0] To be fair, I can autocomplete a lot of that command. GUI is still faster though. "cd/us[tab]/N[tab]/doc[tab]/wo[tab]/2015/08/24/i[tab]/fi[tab].txt"
Lately I've been butting heads with some seriously anti-command line people. I'm not sure if this is a growing sentiment, or I'm just advocating CLI usage more as time goes on. Anyway, glad to see this. I'll be sure to recommend it to whomever I'm preaching.
I can often navigate to a file in a GUI faster than I can "cd users/Nadya/documents/work/2015/08/24/important/file.txt" [0] Or I could open up my GUI, click "work" from my side nav selections and navigate through 2015/08/24/important/ and click my file to open it. I can even open two directories and ^x^v into another directory. Or drag/drop to move. Rather than "mv file.txt ../../25/file.txt" I think it's important t…
It's significantly faster (at least for me and most people I know) to type "cd ~/relevant-symlink" than it is to take my hands off the keyboard, switch to the mouse, and then go back to home row.
Lately I've been butting heads with some seriously anti-command line people. I'm not sure if this is a growing sentiment, or I'm just advocating CLI usage more as time goes on. Anyway, glad to see this. I'll be sure to recommend it to whomever I'm preaching.
I can often navigate to a file in a GUI faster than I can "cd users/Nadya/documents/work/2015/08/24/important/file.txt" [0] Or I could open up my GUI, click "work" from my side nav selections and navigate through 2015/08/24/important/ and click my file to open it. I can even open two directories and ^x^v into another directory. Or drag/drop to move. Rather than "mv file.txt ../../25/file.txt" I think it's important t…
Seriously, if you have 'work' as a side nav, then you could have it as a symlink, which makes it about the same. But it's really the stuff like looping over operations, or rsync over ssh, etc that make reading & writing a bit more awesome than point & grunt.
Ideally IMO there would be a simple test one could take that would open up the later lessons, like a short recap for each chapter rather than working through the whole ls, pwd, cd, ls, pwd, cd, cd .., mkdir, ls -a, ls -l ... at the start.
Earlier quoted context omitted.
I can often navigate to a file in a GUI faster than I can "cd users/Nadya/documents/work/2015/08/24/important/file.txt" [0] Or I could open up my GUI, click "work" from my side nav selections and navigate through 2015/08/24/important/ and click my file to open it. I can even open two directories and ^x^v into another directory. Or drag/drop to move. Rather than "mv file.txt ../../25/file.txt" I think it's important t…
You can't 'cd' to a file :-) Seriously, if you have 'work' as a side nav, then you could have it as a symlink, which makes it about the same. But it's really the stuff like looping over operations, or rsync over ssh, etc that make reading & writing a bit more awesome than point & grunt.
As for symlinks, it's a fair point. But even typing the rest of that example it would be faster for me to use a GUI.
I agree on that point. CLI is much better for less trivial tasks - or making a trivial task possible. On Windows renaming files is bad, ending with an (n) structure. Where I want "file_1.txt, file_2.txt I get file (1).txt, file (2).txt. Or if I save a bunch of .jpf instead of .jpg I have to use the CLI to fix the extensions because it isn't possible in Windows otherwise.
But you won't convince a lot of people to use CLI if you're introducing them to pwd/ls/mv/cp instead of |'s, grep, scripting, etc.
Earlier quoted context omitted.
We teach things like bash by assigning each user to a virtualized Linux server. That gets really expensive and hard to manage when you give one to every anonymous user who hits the site (especially when our courses pop up on sites like HN). With that said, I have been wanting to change the UI to be less intrusive, so you can better see what you're signing up for.
IMHO, A Linux VM for every user sounds like overkill. A separate *NIX user account should be sufficient for teaching things like "Navigating the Filesystem", "Configuring the Environment" etc.
Earlier quoted context omitted.
I can often navigate to a file in a GUI faster than I can "cd users/Nadya/documents/work/2015/08/24/important/file.txt" [0] Or I could open up my GUI, click "work" from my side nav selections and navigate through 2015/08/24/important/ and click my file to open it. I can even open two directories and ^x^v into another directory. Or drag/drop to move. Rather than "mv file.txt ../../25/file.txt" I think it's important t…
You can't 'cd' to a file :-) Seriously, if you have 'work' as a side nav, then you could have it as a symlink, which makes it about the same. But it's really the stuff like looping over operations, or rsync over ssh, etc that make reading & writing a bit more awesome than point & grunt.
I'm routinely tempted to alias `cd` to something that will open the file in $EDITOR, if I type `cd `.