www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Questions about windows support

reply Benjamin Thaut <code benjamin-thaut.de> writes:
1) Is there a chance that dmd will support 64 bit on windows any time 
soon? What are the issues currently with 64 bit support on windows? 
(optlink? backend?)

2) Will dmd support exporting/importing data symbols from dlls? I know 
there is a patch that does the data symbol address patching from the 
runtime but thats a feature that should be supported by the compiler 
directly in my eyes.

3) Am I mistaken or are most of the people here using dmd under linux? 
General bugs or linux only bugs tend to get fixed a lot faster then 
windows only bugs.

Kind Regards
Benjamin Thaut
Feb 20 2012
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, February 20, 2012 22:36:49 Benjamin Thaut wrote:
 1) Is there a chance that dmd will support 64 bit on windows any time
 soon? What are the issues currently with 64 bit support on windows?
 (optlink? backend?)

Neither support 64-bit. So, the changes required to the toolchain are _far_ greater for 64-bit Windows than the Posix OSes. It'll come eventually, but probably not for a while. - Jonathan M Davis
Feb 20 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Feb 20, 2012 at 05:25:28PM -0500, Jonathan M Davis wrote:
 On Monday, February 20, 2012 22:36:49 Benjamin Thaut wrote:
 1) Is there a chance that dmd will support 64 bit on windows any
 time soon? What are the issues currently with 64 bit support on
 windows?  (optlink? backend?)

Neither support 64-bit. So, the changes required to the toolchain are _far_ greater for 64-bit Windows than the Posix OSes. It'll come eventually, but probably not for a while.

Does gdc support 64-bit? AFAIK it should, since it uses the gcc backend. T -- Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. -- Gene Wirchenko
Feb 20 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, February 20, 2012 15:00:28 H. S. Teoh wrote:
 On Mon, Feb 20, 2012 at 05:25:28PM -0500, Jonathan M Davis wrote:
 On Monday, February 20, 2012 22:36:49 Benjamin Thaut wrote:
 1) Is there a chance that dmd will support 64 bit on windows any
 time soon? What are the issues currently with 64 bit support on
 windows? (optlink? backend?)

Neither support 64-bit. So, the changes required to the toolchain are _far_ greater for 64-bit Windows than the Posix OSes. It'll come eventually, but probably not for a while.

[...] Does gdc support 64-bit? AFAIK it should, since it uses the gcc backend.

As I understand it, it does, but I've never used it. - Jonathan M Davis
Feb 20 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Feb 20, 2012 at 06:00:14PM -0500, Jonathan M Davis wrote:
 On Monday, February 20, 2012 15:00:28 H. S. Teoh wrote:
 On Mon, Feb 20, 2012 at 05:25:28PM -0500, Jonathan M Davis wrote:
 On Monday, February 20, 2012 22:36:49 Benjamin Thaut wrote:
 1) Is there a chance that dmd will support 64 bit on windows any
 time soon? What are the issues currently with 64 bit support on
 windows? (optlink? backend?)

Neither support 64-bit. So, the changes required to the toolchain are _far_ greater for 64-bit Windows than the Posix OSes. It'll come eventually, but probably not for a while.

[...] Does gdc support 64-bit? AFAIK it should, since it uses the gcc backend.

As I understand it, it does, but I've never used it.

Well, I guess my question was more along the lines of, does it provide any 64-bit specific advantages? I've been using gdc as my main D compiler, and I'm running 64-bit Linux. Seems to work fine. T -- If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...
Feb 20 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, February 20, 2012 15:04:02 H. S. Teoh wrote:
 On Mon, Feb 20, 2012 at 06:00:14PM -0500, Jonathan M Davis wrote:
 On Monday, February 20, 2012 15:00:28 H. S. Teoh wrote:
 On Mon, Feb 20, 2012 at 05:25:28PM -0500, Jonathan M Davis wrote:
 On Monday, February 20, 2012 22:36:49 Benjamin Thaut wrote:
 1) Is there a chance that dmd will support 64 bit on windows any
 time soon? What are the issues currently with 64 bit support on
 windows? (optlink? backend?)

Neither support 64-bit. So, the changes required to the toolchain are _far_ greater for 64-bit Windows than the Posix OSes. It'll come eventually, but probably not for a while.

[...] Does gdc support 64-bit? AFAIK it should, since it uses the gcc backend.

As I understand it, it does, but I've never used it.

[...] Well, I guess my question was more along the lines of, does it provide any 64-bit specific advantages? I've been using gdc as my main D compiler, and I'm running 64-bit Linux. Seems to work fine.

dmd, gdc, and ldc all use the same front-end. So, aside from code generation, they should be essentially identical. It's whatever the backend does with code generation that results in the difference (such as using COFF instead of OMF on Windows or using a different set of optimizations). - Jonathan M Davis
Feb 20 2012
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 1) Is there a chance that dmd will support 64 bit on windows any time  
 soon?

No. gdc will remain the only option for quite a while. But that's better than dealing with optlink anyway.
 3) Am I mistaken or are most of the people here using dmd under linux?

Yeah, definitely more of a pleasure.
Feb 20 2012
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, February 21, 2012 00:08:32 Trass3r wrote:
 3) Am I mistaken or are most of the people here using dmd under linux?

Yeah, definitely more of a pleasure.

It may be better on the Posix systems, but there are definitely quite a few folks around here who program primarily on Windows, many of whom are major contributors. I don't know which OS most people around here use primarily, let alone the D community as a whole. But I don't think that there's much question that the situation on Windows is the worst of the supported platforms. - Jonathan M Davis
Feb 20 2012
prev sibling next sibling parent reply James Miller <james aatch.net> writes:
On 21 February 2012 12:00, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 On Mon, Feb 20, 2012 at 05:25:28PM -0500, Jonathan M Davis wrote:
 On Monday, February 20, 2012 22:36:49 Benjamin Thaut wrote:
 1) Is there a chance that dmd will support 64 bit on windows any
 time soon? What are the issues currently with 64 bit support on
 windows? =C2=A0(optlink? backend?)

Neither support 64-bit. So, the changes required to the toolchain are _far_ greater for 64-bit Windows than the Posix OSes. It'll come eventually, but probably not for a while.

Does gdc support 64-bit? AFAIK it should, since it uses the gcc backend. T -- Computerese Irregular Verb Conjugation: I have preferences. =C2=A0You hav=

 biases. =C2=A0He/She has prejudices. -- Gene Wirchenko

I use DMD64 on Linux, and it works fine, it puts out 64bit binaries no problem, and it uses the system linker. Windows has not, historically, been a pleasant platform to develop lower-level code for, the default console hasn't been updated in decades (I know that powershell exists), and windows seems to act as if you either use Visual Studio (and .NET) or you aren't a real programmer... -- James Miller
Feb 20 2012
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/20/12 5:21 PM, Adam D. Ruppe wrote:
 On Monday, 20 February 2012 at 23:12:36 UTC, James Miller wrote:
 Windows has not, historically, been a pleasant platform to develop
 lower-level code for

I couldn't disagree with that more, especially if you're comparing to something like linux. The linux console is a big pain.

Interesting viewpoint. Clearly Visual Studio is a great product, but I haven't seen anything as focused as allowing you to get work done as Unix. Andrei
Feb 20 2012
prev sibling next sibling parent reply Juan Manuel Cabo <juanmanuel.cabo gmail.com> writes:
On 02/20/2012 11:06 PM, H. S. Teoh wrote:
 On Tue, Feb 21, 2012 at 02:00:20AM +0100, Adam D. Ruppe wrote:
 ...
 Yeah I remember that. I thought they've since fixed it, though. That's
 more a bash limitation than anything, AFAIK. Besides, what *were* you
 trying to do with such a long command-line anyway? :-)
 ...

I can think of one case where the command line argument limit is a problem: copying or moving files from a huge directory. In that case, to do it with bash, there is no other way around but to do things such as iterate over the alphabet to copy the files that start with 'a', then the ones with 'b'..
 ...
 But then again, I *did* also have to deal with having to repair a remote
 Linux server whose dynamic linker broke, causing basic commands like ls,
 cp, chmod, to be completely non-functional. In fact, *nothing* worked
 except that last remote login running bash. In the end I had to use
 bash's built-in echo command to recreate a statically-linked busybox
 binary via copy-n-pasting over the terminal, in order to get things back
 into working condition again. (Yeah. Definitely not for the faint of
 heart.)
 ...
 
 T
 

That is so COOL!! I remember f*cking up one of my first linux computers that way. If I had known, I wouldn't have to go back to reinstall the many diskettes of slackware (no live cds at that time!, no easy way to fix the fs). --jm
Feb 20 2012
next sibling parent Juan Manuel Cabo <juanmanuel.cabo gmail.com> writes:
 That is so COOL!! I remember f*cking up one of my first linux computers
 that way. If I had known, I wouldn't have to go back to reinstall the
 many diskettes of slackware (no live cds at that time!, no easy way
 to fix the fs).

What happened was (If I remember correctly) that I renamed the /lib directory. (PLEASE DON'T TRY THAT AT HOME!!) Again, this:
 In the end I had to use
 bash's built-in echo command to recreate a statically-linked busybox
 binary via copy-n-pasting over the terminal,


is so cool!! --jm On 02/20/2012 11:56 PM, Juan Manuel Cabo wrote:
 On 02/20/2012 11:06 PM, H. S. Teoh wrote:
 On Tue, Feb 21, 2012 at 02:00:20AM +0100, Adam D. Ruppe wrote:
 ...
 Yeah I remember that. I thought they've since fixed it, though. That's
 more a bash limitation than anything, AFAIK. Besides, what *were* you
 trying to do with such a long command-line anyway? :-)
 ...

I can think of one case where the command line argument limit is a problem: copying or moving files from a huge directory. In that case, to do it with bash, there is no other way around but to do things such as iterate over the alphabet to copy the files that start with 'a', then the ones with 'b'..
 ...
 But then again, I *did* also have to deal with having to repair a remote
 Linux server whose dynamic linker broke, causing basic commands like ls,
 cp, chmod, to be completely non-functional. In fact, *nothing* worked
 except that last remote login running bash. In the end I had to use
 bash's built-in echo command to recreate a statically-linked busybox
 binary via copy-n-pasting over the terminal, in order to get things back
 into working condition again. (Yeah. Definitely not for the faint of
 heart.)
 ...

 T

That is so COOL!! I remember f*cking up one of my first linux computers that way. If I had known, I wouldn't have to go back to reinstall the many diskettes of slackware (no live cds at that time!, no easy way to fix the fs). --jm

Feb 20 2012
prev sibling next sibling parent reply Juan Manuel Cabo <juanmanuel.cabo gmail.com> writes:
I think that the "for x in *" still gets you on the limit (not sure).

This is how you deal with spaces in filenames or '-'

   find -print0 | xargs -0 rm

Another funny unix thing is awk... it solves all your problems but
in one line, but then creates new ones until you get them right
for separators and special cases.

--jm


On 02/21/2012 12:31 AM, H. S. Teoh wrote:
 On Tue, Feb 21, 2012 at 04:24:44AM +0100, Adam D. Ruppe wrote:
 On Tuesday, 21 February 2012 at 03:13:10 UTC, H. S. Teoh wrote:
 for x in *; mv $x dest/$x; done

 Easy. :)

And wrong! What if the filename has a space in it? You can say "$x", with quotes, to handle that.

Argh, you're right. That's one reason I *hate* the implicit interpolation that shells have the tendency to do. Perl got it right: $x means the value of x as a *single* value, no secret additional interpolation, no multiple layers of re-interpretation, and that nonsense.
 But, worse yet... a leading dash? Another downside with the shell
 expansion is the program can't tell if that is an expanded filename or
 a user option.

Heh. Never thought of this before. I can see some fun times to be had with it, though! But you could probably handle it by: mv -- "$x" "$dest/$x"
 In this case, the mv simply wouldn't work, but you can get some
 bizarre behavior out of that if you wanted to play with it.

 try this some day as a joke:

 $ mkdir evil-unix # toy directory
 $ cd evil-unix
 $ touch -- -l # our lol file
 $ touch cool # just to put a file in there
 $ ls
 -l  cool
 $ ls * # the lol file is interpreted as an option!
 -rw-r--r-- 1 me users 0 2012-02-20 22:18 cool
 $


 imagine the poor newb trying to understand that!

+1, LOL. T

Feb 20 2012
parent Juan Manuel Cabo <juanmanuel.cabo gmail.com> writes:
WARNING: for anyone reading dont try this without thinking: !!!!

    find -print0 | xargs -0 rm

Please don't type it as is (that deletes files without problems with spaces or '-', but will delete everything). The -print0 is very useful. I use for instance to see the latest file in a tree of directories: find -type f -print0 | xargs -0 ls -ltr which comes up at the bottom of the listing. --jm On 02/21/2012 12:44 AM, Juan Manuel Cabo wrote:
 I think that the "for x in *" still gets you on the limit (not sure).
 
 This is how you deal with spaces in filenames or '-'
 
    find -print0 | xargs -0 rm
 
 Another funny unix thing is awk... it solves all your problems but
 in one line, but then creates new ones until you get them right
 for separators and special cases.
 
 --jm
 
 
 On 02/21/2012 12:31 AM, H. S. Teoh wrote:
 On Tue, Feb 21, 2012 at 04:24:44AM +0100, Adam D. Ruppe wrote:
 On Tuesday, 21 February 2012 at 03:13:10 UTC, H. S. Teoh wrote:
 for x in *; mv $x dest/$x; done

 Easy. :)

And wrong! What if the filename has a space in it? You can say "$x", with quotes, to handle that.

Argh, you're right. That's one reason I *hate* the implicit interpolation that shells have the tendency to do. Perl got it right: $x means the value of x as a *single* value, no secret additional interpolation, no multiple layers of re-interpretation, and that nonsense.
 But, worse yet... a leading dash? Another downside with the shell
 expansion is the program can't tell if that is an expanded filename or
 a user option.

Heh. Never thought of this before. I can see some fun times to be had with it, though! But you could probably handle it by: mv -- "$x" "$dest/$x"
 In this case, the mv simply wouldn't work, but you can get some
 bizarre behavior out of that if you wanted to play with it.

 try this some day as a joke:

 $ mkdir evil-unix # toy directory
 $ cd evil-unix
 $ touch -- -l # our lol file
 $ touch cool # just to put a file in there
 $ ls
 -l  cool
 $ ls * # the lol file is interpreted as an option!
 -rw-r--r-- 1 me users 0 2012-02-20 22:18 cool
 $


 imagine the poor newb trying to understand that!

+1, LOL. T


Feb 20 2012
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:sjkpvfivljpifhnsavpq forum.dlang.org...
 On Tuesday, 21 February 2012 at 03:30:00 UTC, H. S. Teoh wrote:
 +1, LOL.

I just thought of a better one! -v for grep. grep 'some string' * is something I do a lot; I like that command as generally useful. -v on grep inverts the match. Instead of showing the files with some string, it will show the files *without* some string! I have to use this one some day. Almost April!

Heh, hilarious stuff. Speaking of computer pranks, back in junior high, I was so incredibly bored in this "applied technology" class one day that I wrote a small panic DOS in QBASIC and added it to autoexec.bat. I thought that was worth being banned from the computers in that class for the rest of the semester ;) Well, at least until exams when the teacher *had* to let me back on them for, uhh, whatever it was we had to do as our final (don't recall). Heh, he was pissed. I was surprised when he told me their IT people "had to" format and reinstall the system. I had thought the big QBASIC window coming up upon boot would have been an obvious clue to just Ctrl-Break and then remove qbasic from autoexec.bat. I was thinking, "But...don't IT people know how to use computers?"
Feb 21 2012
prev sibling parent Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
On 02/20/2012 09:31 PM, H. S. Teoh wrote:
 On Tue, Feb 21, 2012 at 04:24:44AM +0100, Adam D. Ruppe wrote:
 On Tuesday, 21 February 2012 at 03:13:10 UTC, H. S. Teoh wrote:
 for x in *; mv $x dest/$x; done

 Easy. :)

And wrong! What if the filename has a space in it? You can say "$x", with quotes, to handle that.

Argh, you're right. That's one reason I *hate* the implicit interpolation that shells have the tendency to do. Perl got it right: $x means the value of x as a *single* value, no secret additional interpolation, no multiple layers of re-interpretation, and that nonsense.
 But, worse yet... a leading dash? Another downside with the shell
 expansion is the program can't tell if that is an expanded filename or
 a user option.

Heh. Never thought of this before. I can see some fun times to be had with it, though! But you could probably handle it by: mv -- "$x" "$dest/$x"
 In this case, the mv simply wouldn't work, but you can get some
 bizarre behavior out of that if you wanted to play with it.

 try this some day as a joke:

 $ mkdir evil-unix # toy directory
 $ cd evil-unix
 $ touch -- -l # our lol file
 $ touch cool # just to put a file in there
 $ ls
 -l  cool
 $ ls * # the lol file is interpreted as an option!
 -rw-r--r-- 1 me users 0 2012-02-20 22:18 cool
 $


 imagine the poor newb trying to understand that!

+1, LOL. T

rsync -aAHX src dest && rm -fr src ---------- Christopher Nicholson-Sauls
Feb 23 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
Many only know the UNIX version of Linux or BSD, but lets not forget the
idiosyncrasies any developer faces when having to support multiple 
commercial
UNIX systems in spite of standards like POSIX.

I still remember the first time I loggeded into an HP-UX system in a 
production system
at one of our customers, back in 2000. It was like time travel to the 70's.

The same can be said of Solaris. My first task after setting up a Solaris 
server (v6-8) was
always to go to a repository like Sunfreeware and get a set of sane userland 
tools.

These are just two stories, but I have many to share from our support 
between Windows and
UNIX flavours we had to support (Linux, BSD, Aix, HP-UX, Solaris and Aix).

Sure Windows is sometimes a pain to work with, but commercial UNIXes are not 
far off.

--
Paulo

"Adam D. Ruppe"  wrote in message 
news:cekchlmrcfupiocywkfv forum.dlang.org...

On Tuesday, 21 February 2012 at 00:37:33 UTC, H. S. Teoh wrote:
 Weird. I guess I must be a very strange person, because I find that my 
 productivity soars at the command-line

Me too. Command line rocks, and bash is a fine shell. (csh sucks though, why its the default on so many bsds is beyond me.) What I'm talking about here is the underlying technology and ease of programming. It isn't difficult to get a compiler on Windows and write code. You can use Visual Studio, or notepad, or anything in between. You can write a lot of code easily, from 16 bit DOS programs (well, not anymore on 64 bit, but you could for a long, long time) up to gui apps, including doing console apps that have an api similar to vga text hardware. On Linux, you have to worry about terminal escape sequences, libc incompatibilities, and all kinds of other stuff to write similar programs. Remember though, that this isn't about the shell or userland. I really like the Linux command line (though it isn't perfect... ever gotten "command line too long" due to how * is expanded by the shell? Ugh.). But anyway I really like it, but the operating system isn't any easier to program for. Indeed, if you want to distribute your app, it is a lot harder due to compatibility. Windows apps tend to just work.
Feb 21 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:hmldxgffvfeyydarulig forum.dlang.org...
The ugly escape sequences showed through to the end user (me)!

I'm not as experienced in Unix as you are, but there's some smaller quirks I've noticed. For instance, if you're in the terminal and use the arrow keys while a foreground process is running (and not prompting for input) you'll get: ^[[D^[[A^[[C^[[B Or if you hit any arrow key right before typing a password you're being prompted for, it'll think you meant it as part of the password and it'll fail.
 But I agree with you though, that libc incompatibilities are really 
 really REALLY annoying.

Even worse is linux's binary incompatibilities. The dmd in the zip doesn't work out of the box on centos for instance... have to recompile it.

Yea, those binary/libc incompatibilities are a pain if you're used to the Windows world. Another issue with it is that to make a binary work on both an older and newer Linux, you have to actually compile it *on* an older Linux. I've heard that, in theory, you can use a newer Linux to create binaries that work on older systems, but in practice, nobody actually knows how.
 That's more a bash limitation than anything, AFAIK.

Yes and no. bash (and the kernel) is good about it now, but it is an effect of the unix design of the shell doing the expansion. rm * could have sent argv == ["rm", "*"], and your app simply done foreach(a; glob(argv[1..$])) { delete(a); } or whatever. But, unix decided to do this in the shell. Which isn't all bad, it has some nice effects. But, run that in a folder with 20,000 items, and you send 20,000 strings in argv...

Eeeww. I had no idea the shell did the expansion. That's just awful.
 Most distros do distribute prebuilt binaries, but if your app isn't part 
 of the distribution, things get tough.

Aye, or if the version you need isn't in there. centos, I'm looking at you!

Maybe I don't understand the way the package/dep managers work well enough, but it always seemed bad to me that you can't do: $sudo apt-get install [url to an apt-compatible package] Or whatever the yum equivalent would be. Erm, at least, I don't *think* you can...Maybe I'm wrong? In any case, having to mess with the sources list sucks. Linux is definitely groing on me more and more, but you're right, it does have it's quirks.
Feb 21 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 24, 2012 at 05:19:44PM +0100, Adam D. Ruppe wrote:
 On Thursday, 23 February 2012 at 19:10:03 UTC, H. S. Teoh wrote:

The echo command has a bug, it's not supposed to output 'echo' as
part of its output. :)

Yeah, I messed up argv. Here's an updated version: http://arsdnet.net/dcode/dshell.d added basic formatting to the data interface, lazy printing (try "cat" and type in stdin) and bug fixes.

OK I'll take a look at it. [...]
It's extremely cool. Definitely orders of magnitude better than
writing the equivalent thing in C.

Hell, this kind of thing is easier in D than in a lot of dynamic languages! imo anyway. eval is sometimes nice but having the type information available to do a smart wrapper is very nice.

Well, eval is just runtime mixin. From the program's POV, it's an opaque string that might do just about *anything*. Which is not very helpful since you can't really do too much with it except to run it or not. Type introspection OTOH allows you do more intelligent things based on what types are there. T -- WINDOWS = Will Install Needless Data On Whole System -- CompuMan
Feb 24 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:veaiisjzbijgdjbzwjif forum.dlang.org...
 On Tuesday, 21 February 2012 at 03:53:20 UTC, H. S. Teoh wrote:

 Heh, never seen that before. I usually just turn off all fancy settings
 after installing a new system, and just stick with a bare-bones prompt.

I like slackware's default of \u \h:\w\$ Simple, informative, reliable.

That's default on Debian and Ubuntu, too. And if you're root, the "$" changes to "#" (I think that's pretty common though...?). I used to find the "\u \h" kinda pointless, especially the " \h" part. But now that I'm dealing more and more with multiple machines/VMs/users, ssh, etc., I absolutely love it.
 But, one of the sysadmins I worked with fell in love with
 colors. I still have access to one of his systems, let
 me pull this up... this system is slow! come on...

 Here we go:
 # echo $PS1
 \033[0m\033[36mname\033[34mredacted\033[0m#

 Two different colors forming the system's name! And no
 useful info. This isn't a prompt. It's a logo.

Hmm yea. I never could stand prompts that didn't at least include the working dir. It's pretty though! Crap, now I want to color-code the user and host parts of my prompts...Especially for root and live production servers, that could be downright useful: Big bright right "This is ROOT!!!", or "This is LIVE PRODUCTION SERVER!!!" staring you in the face.
 Only seven years? ;-) I've been at it for several years longer.

I'm relatively new but just as grizzled :-)

I started about 11 years ago, but only on an occasional basis (and there was a big gap of a few years in the middle). It's been nowhere near permanent day-to-day (though that's slowly changing). So I'm practically a newbie by comparison.
 Fond memories here of video mode 13h too. That was
 easy programming, and good speed too, even on those
 old computers.

God yes. 0xA0000 forever! :) And on a related note, long live Future Crew!
 When I finally switched to coding for these
 newfangled multitasking OSes, it took a long time
 to get used to not having my precious memory map.

I remember that playing high-end games in Windows (thanks to GameSDK/DirectX) just felt very weird. Took some getting used too. Actaully, even now I'm not a real huge fan of it. The multitasking can still cause stutters and such that never occur when games are able to take over 99% of the system.
 With Linux users, there's always some list of third
 party stuff they need too. dmd, qt, whatever, but
 always something.

I had loads of fun with dependencies when I tried to compile Git from source a few weeks ago. (Not as bad as pre-yum rpm's though.)
Feb 21 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ji0s7e$81a$1 digitalmars.com...
 It's pretty though! Crap, now I want to color-code the user and host parts 
 of my prompts...Especially for root and live production servers, that 
 could be downright useful: Big bright right "This is ROOT!!!", or "This is 
 LIVE PRODUCTION SERVER!!!" staring you in the face.

"Big bright right..." == "Big bright red background..." I don't know how the hell I managed that typo...
Feb 21 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ji0s7e$81a$1 digitalmars.com...
 "Adam D. Ruppe" <destructionator gmail.com> wrote in message 
 news:veaiisjzbijgdjbzwjif forum.dlang.org...
 On Tuesday, 21 February 2012 at 03:53:20 UTC, H. S. Teoh wrote:

 Heh, never seen that before. I usually just turn off all fancy settings
 after installing a new system, and just stick with a bare-bones prompt.

I like slackware's default of \u \h:\w\$ Simple, informative, reliable.

That's default on Debian and Ubuntu, too. And if you're root, the "$" changes to "#" (I think that's pretty common though...?). I used to find the "\u \h" kinda pointless, especially the " \h" part. But now that I'm dealing more and more with multiple machines/VMs/users, ssh, etc., I absolutely love it.

On other thing I meant to mention: It's kinda annoying on Linux how if you launch a gui app at the command line, it will automatically be a blocking foreground process unless you remember to add "&" at the end. Which I always forget. And even then, a lot of GUI apps (most notably KDE) will flood the cmd window with stdout/stdin. On windows, none of that happends: whenever you launch a process from the command line it does the most useful thing depending if it's a GUI or cmdline app. I had so much trouble getting used to the Linus behavior I created a couple tiny scripts to help out: $ cat ~/bin/gui #!/bin/sh "$ " > /dev/null 2> /dev/null & $ cat ~/bin/guisudo #!/bin/sh gui kdesudo "$ " I still have to remember to prepend each gui-lauching command with "gui " or "guisudo ", but it works a lot better for me (except when the command I typed doesn't exist and I don't get any message saying so). Again, Linux's comand line totally blows Windows out of the water, no doubt, but there are still a few niceities with Windows. Another one is that in windows, it's possible for a batch script to export env vars when it chooses too. Granted, it's done in an *extremely* sloppy and haphazard way, and it shouldn't be the default, but at least it's possible. I totally understand the technical and hygenic reasons why Linux requires scripts to be sourced for their env var exports to...well, be exported, but the fact that it's impossible for the script to override that forces DVM, for instance, to stick a "dvm" shell function inside '.bashrc'. Otherwise, you'd have to remember to run it like ". dvm use 2.058" for it to actualy work. On windows, when you type "dvm ..." it just runs an ordinary batch file.
Feb 21 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:bexfgnarfyprlvslmksn forum.dlang.org...
 On Tuesday, 21 February 2012 at 22:26:34 UTC, Nick Sabalausky wrote:
 On other thing I meant to mention: It's kinda annoying on Linux how if 
 you launch a gui app at the command line, it will
 automatically be a blocking foreground process unless
 you remember to add "&" at the end. Which I always forget.

You can also hit ctrl+z in that terminal to pause the gui app, then hit "bg" in there to move it to the background. Tho it still spams the text iirc.

That hadn't occurred to me. Thanks. Normally, the only time I use fg/bg is if I try to cancel something with Ctrl-blah and it suspends the process instead of stopping it. So then I "fg [whatever num]" and either try a different key combo or let it finish. But still, I'd venture to say that probably 99.9% of the times you launch a gui app from the command line, you don't want, or at least don't need, it to be blocking or spamming the console. It'd be nice if it could do like windows and detect "gui or cmdline" so it can automatically do the right thing without the user coddling it. Unfortunately I'm not sure that's possible since I don't think Linux binaries are flagged as "cmdline or gui" like in windows. It just either calls some GUI apis or it doesn't. That reminds me of another thing (yea, I know I sounds like I'm just ranting on and on about Linux, but I *do* rather like it overall): What the hell is up with this "sudo" vs "gtksudo/kdesudo" shit? I understand that it's somehow necessary for the permissions/process-owner stuff to all be right, but why should *that* be necessary? The whole Unix philosophy is orthogonality, one tool to do one task well, no duplicated functionality for slightly-different use cases. The whole "sudo" vs "gtksudo/kdesudo" thing seems to be some sort of big ugly hack.
 I kinda like how linux apps keep it though. It's just so
 easy to throw in a printf() from time to time to tell something
 to me without doing a popup window or something.

Yea. I think though, that *those* cases are the ones for which there should be some special way of launching the process. The typical case as the default, the exceptional case as an option. Not the other way around.
Feb 21 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Bernard Helyer" <b.helyer gmail.com> wrote in message 
news:iianhomhapvkfhidezbr forum.dlang.org...
Nick replied to something about globbing

who doesn't play ball. *cough* every single digital mars utility *cough*. I think Windows and unix both get it wrong, but unix gets it less wrong (as it could theoretically be annoying, but in practice I just escape it and move on, but working around a non-globbing program is just annoying). Wot I think should happen: the runtime (say libc) should handle globbing of arguments, and it should be enabled by default. So if someone wants an app that handles wildcards specially, they can do that, but for most apps it'll just workT. I don't think this really meshes with the traditional main signature of just passing the strings as arguments. Perhaps just a non_globbed_args function or something. Buuuut things are pretty much set in stone at this point.

I dunno about that. The problem is that in the default "just work" case, the app still has no idea that the shell is sending it things that are *supposed* to be interpreted as filenames, so you still end up with that "touch -- --ha-ha-fuck-you" fiasco. Also, libc/whatever has no way to know when a glob does or doesn't even make sence in the first place. What if you want to do something like: "fooapp --special-files=blah*.baz" The app knows how to handle that right, but if fooapp's authot forgot to disable the autoglob, the runtime will just fuck it up and remove the arg entirely (unless some jackwagon previously did "touch -- --special-files=blahblah.baz"). Or if the app allowed "fooapp --regex r/blah*blah/" which wasn't even *intended* to be a glob. In that case, too, the app itself would have *make sure* to remember to disable the default setting so it works right. It'd just be another thing for developers to watch out for and possibly screw up. I think that globbing should be done explicity by the app, *but* for apps that don't play ball you should be able to *explicitly* do it at the command line. Example: $someutil *.txt foo.html ERROR: Can't find file '*.txt' $glob *.txt 'hello.txt' 'Modern File Name.txt' 'another.txt' $someutil `glob *.txt` foo.html Processing hello.txt...done Processing Modern File Name.txt...done Processing another.txt...done Processing foo.html...done Erm...actually, that glob tool above would probably have to work more like this: $glob *.txt 'hello.txt' 'Modern File Name.txt' 'another.txt'$someutil `glob *.txt` Processing hello.txt...done [etc...] Which brings up another little nitpick: When bash displays a prompt, it should first check to see if the last char output was a newline. If not, it should...ADD ONE!
Feb 21 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 01:33:56AM +0100, Adam D. Ruppe wrote:
 Thinking about globbing, I think rm * is a mistake
 anyway...
 
 The way I'd do programs is something like this:
 
 echo input > program_name options....
 
 So, you wouldn't rm *. You'd ls | rm.
 
 You'd implement rm like this:
 void main() {
      foreach(file; stdin.byLine)
          std.file.remove(file);
 }

Hmm. Let's implement shell utilities in D! (Pointless, yeah, but a fun exercise to see how much cleaner D code can be -- if you've ever looked at that creeping horror that is the source code for 'less'.) [...]
 This way, options and things to operate on
 are nicely separated, and you can process
 the input with more filters easily.
 
 glob * | grep 'poo' | rm

Interesting idea. This calls for ... a shell written in D. :-) [...]
 Windows Powershell actually kinda works this way,
 from what I know of it. You can do
 
 ps | kill
 
 and it works.

Nice. [...]
 I almost *almost* want to write my own custom userland.

Only? Heh... when I was young and foolish, I wanted to trump Linus and write my own kernel. But seriously, I *do* contemplate from time to time about writing my own shell. I have lots of beefs against the way current shells are implemented, globbing being one of them, or more generally, excessive implicit interpolation, that turns something simple like \00 into nonsense like \\\\0000. My concept of shell is to make it a very thin (but scriptable) layer over actual syscalls, so you could do something like: % open data.txt &3: /home/data.txt # data.txt bound to &3 % send &3 | grep abc # pipe data.txt to grep abcdef # output from grep % echo # stands for "last output" abcdef % write &3 # write "abcdef" to data.txt % close &3 # detach data.txt But I haven't actually sat down to think this through, so I don't know if how practical/usable this will turn out to be. Maybe this will be my next D project. :P
 But, while I can complain all day about what we have...
 meh it works well enough that I'm in no rush to spend
 a lot of time replacing it.

True. T -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous
Feb 21 2012
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 22 February 2012 at 02:03:58 UTC, H. S. Teoh wrote:
 Hmm. Let's implement shell utilities in D! (Pointless, yeah, 
 but a fun exercise to see how much cleaner D code can be -- if 
 you've

I'm sooo tempted again. Though, I don't really like shell utilities.... I'd want many of them to be accessible through api, and at that point, might as well just do them all as built ins. I guess if there's another file available, we can call it instead to allow easy replacement, but I just think making the shell there as a library is a really nice thing. class ShellOperations { /* methods here */ } then use compile time reflection to build your map for the command line processing.... Our D shell could be just one program. though tbh if I was doing a shell, I'd kinda want to do a terminal replacement too. But, I don't see myself leaving xterm and rxvt. Nor putty. idk, should probably limit the scope a bit just to make it realistic to finish. Use gnu readline too and piggyback on that pretty nice function for history, editing, completion, etc. Actually that makes it fairly doable as a weekend project.
 Only? Heh... when I was young and foolish, I wanted to trump 
 Linus and write my own kernel.

I've tried it before.... but it is terribly boring. As cool as it is to say "every line of code on that box is mine and mine alone", that's all it is good for imo: bragging. The interesting stuff is all user territory.
 My concept of shell is to make it a very thin (but scriptable) 
 layer over actual syscalls, so you could do something like:

Eeeeeeh.... at that point, you might as well just write your commands in C (or D). I actually like bash a lot... but only for 1-3 line things. Bigger than that, and screw it, I'd rather just write C/D. bash is a huge pain to get anything done for > 3 lines... But for those 1-3 line things, it is really nice. And, since it is a command line shell, that's exactly what it should be optimizing!
Feb 21 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 24, 2012 at 02:32:38PM +1300, James Miller wrote:
[...]
 I have tried to keep the scope of what the graphics capabilities of
 the terminal are down to a minimum, so all the drawing would still be
 in terms of the terminal. I was thinking that you put it into graphics
 mode, say how many columns and rows you want, and the length of the
 data  (so as to not accidentally leave image mode because the data
 contains the escape sequence for leaving image mode) It would start
 drawing in a rectangle from cursor location, and leave the cursor in
 the column after the last. I haven't decided what would happen if you
 didn't have enough columns (rows would just scroll), or how you'd deal
 with images that don't fit into character block pixel sizes.

You could just pad the unused space with blank pixels.
 So you could implement a fully graphical system inside it, but it
 would be a lot of work, and you wouldn't have the advantage of any
 windowing features, and everything would still be cursor-based anyway.

Right, 'cos the point isn't to implement a windowing system, but just to add graphical display capabilities to the terminal.
 Basically the idea is to make it easy to implement features that make
 sense in a terminal, but make it difficult to do anything outside that
 scope. So I probably wouldn't have a subwindow, since that instantly
 provides way too much functionality, also you could output pictures
 fine simply by decoding the pictures into some "raw" format
 (preferably something that can be mapped straight to a pixbuf) and
 outputting them, video could work by just doing the same thing, but
 moving the cursor back to the original starting point over-and-over.

Yeah that's pretty good basic functionality IMHO. Quite often I've wanted to write up some throwaway character-based games with graphical icons, and something like this would be perfectly suited. Usually these little games are just quick-n-dirty write-once-and-forget deals, so I really don't want to be dealing with the complexities of using X11 or SDL, but just to be able to say, character code X maps to image Y, draw this at character position (43,21). Job done. [...]
 I guess the idea is that being able to, for example, display pictures
 in your otherwise-terminal-based mail app is useful, being able to
 preview files without opening a new window (useful for people with
 tiling managers, like me) is useful. But having something that tries
 to be a window manager, or a proper app, is not useful. By having a
 layer of indirection, and the performance penalty that holds, trying
 to maintain terminal context, and making it unidirectional, it
 essentially forces apps to not abuse the capability, its not feasible
 to do anything other than just display an image.

Agreed.
 There are a few other idea I have, but aren't even close to being
 properly formed yet, however the simple-to-use graphics capabilities
 described above is something that I think has real merit. I've seen a
 few similar things in the past, but I don't think they tried to be a
 terminal emulator in their own right, so I couldn't run vim or screen
 in them.

I think this has merit. It lets you do quick-n-dirty apps with simple graphical icons without needing to invest the effort into a full-fledged GUI app complete with a full windowing toolkit and configurable fonts. Sometimes just an icon or two in the midst of some text really is just good enough. T -- "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. -- (Stolen from the net)
Feb 24 2012
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 24 February 2012 at 17:54:47 UTC, H. S. Teoh wrote:
 You could just pad the unused space with blank pixels.

whoa, make a tile based system, like the NES. There's a private use area in unicode, 16 bits of space I think. You could define a tile set to use that, or a simple bitmap format, but it isn't enough room to do on demand tiles I think. Imagine this though, your terminal lets the app define new characters, in color. The protocol might be an escape sequence then you go ahead and write out an image using whatever format (xpm or base64 png - something you can easily enough represent as text.) Then, you overwrite a private use character. You can then write that character to display the custom glyph. Now, you treat it just like any other character for writing, scrolling, read back, etc. Mixes right in with text. Now, you won't be able to just "cat image.png", but you could write a cat that does it. Define a tileset for a line, write it out, repeat and let it scroll to show the whole image. 65535 * what's a character size, like 13x9, something like that? You could write out a nice, big image without worrying about tile reuse. I think I like this..., it'd fit pretty well with the existing terminal setup and add the new functions.
Feb 24 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 20 February 2012 at 23:12:36 UTC, James Miller wrote:
 Windows has not, historically, been a pleasant platform to 
 develop lower-level code for

I couldn't disagree with that more, especially if you're comparing to something like linux. The linux console is a big pain. dmd works pretty well on Windows (building 32 bit apps, no 64). The biggest problem is good old optlink, while the best of the bunch in the 90's, doesn't work so well with all the newer stuff people want to use today. Can't really blame Windows for that, though.
Feb 20 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 11:35:09PM +0100, Adam D. Ruppe wrote:
 On Tuesday, 21 February 2012 at 22:26:34 UTC, Nick Sabalausky wrote:
On other thing I meant to mention: It's kinda annoying on Linux
how if you launch a gui app at the command line, it will
automatically be a blocking foreground process unless
you remember to add "&" at the end. Which I always forget.

You can also hit ctrl+z in that terminal to pause the gui app, then hit "bg" in there to move it to the background. Tho it still spams the text iirc.

You can do: program_name >/dev/null 2>&1 & That will silence everything. But yeah, too much typing, too much obscure stdout/stderr redirecting for a newbie to even begin to dream that such things are possible. A good default behaviour (for the app writer) is to fork() at startup, detach from pty in child, and then exit parent. A couple o' programs do this.
 I kinda like how linux apps keep it though. It's just so easy to throw
 in a printf() from time to time to tell something to me without doing
 a popup window or something.

You can disable the fork() in debug builds (or with a -debug flag) so that you can still get error messages out of it when something goes wrong. I'm pretty sure this is common knowledge, just that nobody bothers to do it. But I can dream. :) T -- The two rules of success: 1. Don't tell everything you know. -- YHL
Feb 21 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.824.1329867308.20196.digitalmars-d puremagic.com...
 You can do:

 program_name >/dev/null 2>&1 &

 That will silence everything. But yeah, too much typing, too much
 obscure stdout/stderr redirecting for a newbie to even begin to dream
 that such things are possible.

 A good default behaviour (for the app writer) is to fork() at startup,
 detach from pty in child, and then exit parent.  A couple o' programs do
 this.

Clever, I like it! I'm gonna try to remember that next time I start doing desktop-GUI stuff again.
 I'm pretty sure this is common knowledge, just that nobody bothers to do
 it. But I can dream. :)

It's news to me, but then again, I'm far from being a Linux veteran. There are a *lot* of things to know about in Linux, though, and there's no standard learner's curriculum. I wouldn't be surprised if there's a lot of experienced Linux users that don't know at least one or two "basic" things. Hell I bet my knowledge is probably a mix of "some of the basics" and "some of the advanced".
Feb 21 2012
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 21 February 2012 at 23:35:09 UTC, H. S. Teoh wrote:
 That will silence everything. But yeah, too much typing

Yea.
 I'm pretty sure this is common knowledge, just that nobody 
 bothers to do it. But I can dream. :)

Yeah, though I've only seen it suggested for daemon like programs... I think you're the first person who I've seen suggest it for gui apps too. Not a bad idea.
Feb 21 2012
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Benjamin Thaut" <code benjamin-thaut.de> wrote in message 
news:jhuedi$22k1$1 digitalmars.com...
 3) Am I mistaken or are most of the people here using dmd under linux? 
 General bugs or linux only bugs tend to get fixed a lot faster then 
 windows only bugs.

I'm primarily Windows. (Although I also test all my code under Linux 32/64)
Feb 20 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, February 21, 2012 00:21:33 Adam D. Ruppe wrote:
 On Monday, 20 February 2012 at 23:12:36 UTC, James Miller wrote:
 Windows has not, historically, been a pleasant platform to
 develop lower-level code for

I couldn't disagree with that more, especially if you're comparing to something like linux. The linux console is a big pain.

I think that it's at least somewhat a matter of what you're used to. I would consider the Windows console to be junk in comparison to the Linux console, but I'm almost always in Linux. I'm not sure that I've ever heard anyone say anything about the Windows console being better than the Linux console before. If I hear anything like that, it's always the opposite. - Jonathan M Davis
Feb 20 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/20/12 6:25 PM, Adam D. Ruppe wrote:
 On Tuesday, 21 February 2012 at 00:19:47 UTC, Jonathan M Davis wrote:
 In my experience, you only run into weird terminal nonsense
 with old computers or maybe sometimes with ssh. Other than
 that, there aren't any weird problems like that.

It happens a lot if you use a lot of different unixes. ssh from Linux into BSD, for example, and it is easy to hit these incompatibilities.

ssh into Windows and... well last time I did it it was like "welcome to Hell". Andrei
Feb 20 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/20/12 6:41 PM, Adam D. Ruppe wrote:
 On Tuesday, 21 February 2012 at 00:38:46 UTC, Andrei Alexandrescu wrote:
 ssh into Windows and... well last time I did it it was like "welcome
 to Hell".

Oh, certainly!

Rats. I was hoping the boys in Redmond have improved the situ since. Andrei
Feb 20 2012
parent "Paulo Pinto" <pjmlp progtools.org> writes:
They did, but Microsoft way as usual.

SSH in Windows, means making use of Powershell remote access. SSH is only 
meant
for UNIX compatibility and it works better if SUA (UNIX personality) is also 
installed.

--
Paulo

"Andrei Alexandrescu"  wrote in message 
news:jhupcv$2l7j$1 digitalmars.com...

On 2/20/12 6:41 PM, Adam D. Ruppe wrote:
 On Tuesday, 21 February 2012 at 00:38:46 UTC, Andrei Alexandrescu wrote:
 ssh into Windows and... well last time I did it it was like "welcome
 to Hell".

Oh, certainly!

Rats. I was hoping the boys in Redmond have improved the situ since. Andrei
Feb 21 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:epzlyfzibmpuoilawaqz forum.dlang.org...
 On Tuesday, 21 February 2012 at 00:38:46 UTC, Andrei Alexandrescu wrote:
 ssh into Windows and... well last time I did it it was like "welcome to 
 Hell".

Oh, certainly!

Does anyone suppose it would work better (or at all) to ssh into MSYS/MinGW? Anyone tried? Also I'm curious: what sort of problems were there ssh-ing into win?
Feb 21 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
This is just a guess, since I've mostly used GUI access (VNC, Citrix and 
lately RDP).

I would say SSH use in Windows is quite limited, depending on what you want 
to do,
because historically most Windows developers lack the culture to separate 
application code
from UI, which leads to many applications to be available in GUI form only.

This has been changing in the last years since Microsoft introduced 
Powershell and due
to market pressure created headless versions of Windows. But even if 
Microsoft
would do everything the correct way, programmer culture takes years to 
change.

--
Paulo

"Nick Sabalausky"  wrote in message news:ji0fb2$2hbp$1 digitalmars.com...

"Adam D. Ruppe" <destructionator gmail.com> wrote in message
news:epzlyfzibmpuoilawaqz forum.dlang.org...
 On Tuesday, 21 February 2012 at 00:38:46 UTC, Andrei Alexandrescu wrote:
 ssh into Windows and... well last time I did it it was like "welcome to 
 Hell".

Oh, certainly!

Does anyone suppose it would work better (or at all) to ssh into MSYS/MinGW? Anyone tried? Also I'm curious: what sort of problems were there ssh-ing into win?
Feb 21 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.860.1329924869.20196.digitalmars-d puremagic.com...
 On Wed, Feb 22, 2012 at 08:53:06AM +0100, Paulo Pinto wrote:
 [...]
 This has been changing in the last years since Microsoft introduced
 Powershell and due to market pressure created headless versions of
 Windows.

Wow. Headless Windows? Can it even be called Windows anymore? :)

Microsoft Drywall :)
Feb 22 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 11:08:41AM -0500, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.860.1329924869.20196.digitalmars-d puremagic.com...
 On Wed, Feb 22, 2012 at 08:53:06AM +0100, Paulo Pinto wrote:
 [...]
 This has been changing in the last years since Microsoft introduced
 Powershell and due to market pressure created headless versions of
 Windows.

Wow. Headless Windows? Can it even be called Windows anymore? :)

Microsoft Drywall :)

LOL On a more serious note, this is perhaps a proof that it's not a good idea to conflate the OS with the GUI. :) But then I'm just being pedantic. T -- If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen
Feb 22 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.865.1329932055.20196.digitalmars-d puremagic.com...
 On Wed, Feb 22, 2012 at 11:08:41AM -0500, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.860.1329924869.20196.digitalmars-d puremagic.com...
 On Wed, Feb 22, 2012 at 08:53:06AM +0100, Paulo Pinto wrote:
 [...]
 This has been changing in the last years since Microsoft introduced
 Powershell and due to market pressure created headless versions of
 Windows.

Wow. Headless Windows? Can it even be called Windows anymore? :)

Microsoft Drywall :)

LOL On a more serious note, this is perhaps a proof that it's not a good idea to conflate the OS with the GUI. :) But then I'm just being pedantic.

I've thought about that, and always been conflicted on it. User-choice and configurability is great, but OTOH there's something to be said about being able to assume one GUI system and not worry about a program or a set of instructions working on KDE *and* GNOME *and* xfce *and* lxde *and* blackbox *and* afterstep (is that still in use?) *and* etc... It'd be great if we could just have one GUI that's flexible/customizable/efficient enough for everyone. But then, problem is half the GUIs out there are *all* trying to be that "one and only" GUI. Oh well.
 If you think you are too small to make a difference, try sleeping in a 
 closed room with a mosquito. -- Jan van Steenbergen

Heh, you've got some good quotes. I also really liked that one about "Why didn't he append 'I think' to 'wiser people are so full of doubts'?"
Feb 22 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 22 February 2012 at 17:34:16 UTC, H. S. Teoh wrote:
 On a more serious note, this is perhaps a proof that it's not a 
 good
 idea to conflate the OS with the GUI. :) But then I'm just being
 pedantic.

Do you wanna say modern hardware still can't run GUI system?
Feb 22 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 20 February 2012 at 23:51:38 UTC, Jonathan M Davis 
wrote:
 I would consider the Windows console to be junk in
 comparison to the Linux console, but I'm almost always in Linux.

Are you talking about the console, or the shell (and ecosystem)? The linux shells are a lot easier to use than cmd.exe for the most point, but programming is another story. Windows console is like something from the 80's. Linux terminals is like ten incompatible things, all from the 70's. A lot of nonsense you have to worry about - character encoding for input and output, the escape sequences, again in and out (ever use a linux terminal where your arrow keys didn't work? Ever have to press escape twice? This sucks for programming and using.) Huge pain in the butt.
Feb 20 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, February 21, 2012 01:11:33 Adam D. Ruppe wrote:
 On Monday, 20 February 2012 at 23:51:38 UTC, Jonathan M Davis
 
 wrote:
 I would consider the Windows console to be junk in
 comparison to the Linux console, but I'm almost always in Linux.

Are you talking about the console, or the shell (and ecosystem)? The linux shells are a lot easier to use than cmd.exe for the most point, but programming is another story. Windows console is like something from the 80's. Linux terminals is like ten incompatible things, all from the 70's. A lot of nonsense you have to worry about - character encoding for input and output, the escape sequences, again in and out (ever use a linux terminal where your arrow keys didn't work? Ever have to press escape twice? This sucks for programming and using.) Huge pain in the butt.

I'm talking bash vs cmd.exe. In my experience, you only run into weird terminal nonsense with old computers or maybe sometimes with ssh. Other than that, there aren't any weird problems like that. - Jonathan M Davis
Feb 20 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 07:36:24PM +0100, Kagamin wrote:
 On Wednesday, 22 February 2012 at 17:34:16 UTC, H. S. Teoh wrote:
On a more serious note, this is perhaps a proof that it's not a good
idea to conflate the OS with the GUI. :) But then I'm just being
pedantic.

Do you wanna say modern hardware still can't run GUI system?

That's not what I mean. When your OS is running on a dedicated remote server, it makes no sense to have a GUI running on it, since all administration is done remotely anyway. A GUI on a server is just a waste of resources. T -- Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
Feb 22 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 01:14:46PM -0500, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 

 On a more serious note, this is perhaps a proof that it's not a good
 idea to conflate the OS with the GUI. :) But then I'm just being
 pedantic.

I've thought about that, and always been conflicted on it. User-choice and configurability is great, but OTOH there's something to be said about being able to assume one GUI system and not worry about a program or a set of instructions working on KDE *and* GNOME *and* xfce *and* lxde *and* blackbox *and* afterstep (is that still in use?) *and* etc... It'd be great if we could just have one GUI that's flexible/customizable/efficient enough for everyone.

I thought that was called X11? Oh wait... ;-) The problem with X11 is that it was designed almost 30 years ago, and as a result its API is, by today's standard, rather baroque. It was also from a time before the dominance of the so-called desktop metaphor, which means many contemporary programs require a lot more infrastructure than it provides. Which is why KDE and GNOME exist. I've always been a stickler for configurability. But I can see the value of having a consistent set of instructions for a newbie to follow when she encounters problems with your app. If everyone has a different setup then tech support is a veritable waking nightmare. Perhaps the solution is to have a single *default* desktop, and then power users can configure it to their hearts' content, with the caveat that if things go wrong, they're on their own. Power users ought to know how to translate instructions intended for the default desktop to their own environment anyway. For example, I don't think *anyone* could give me sane instructions that would work on my "desktop"... which is more like a glorified console than a real desktop. :P But if you said something like "go to applications -> browsers, click on Firefox", then I'd just smile and nod and type "firefox&" at the shell prompt. :)
 But then, problem is half the GUIs out there are *all* trying to be
 that "one and only" GUI. Oh well.

To me, one GUI has already won, and it's called rxvt. ;-)
 If you think you are too small to make a difference, try sleeping in
 a closed room with a mosquito. -- Jan van Steenbergen

Heh, you've got some good quotes. I also really liked that one about "Why didn't he append 'I think' to 'wiser people are so full of doubts'?"

Here's one of my all-time favorites: T -- There is no gravity. The earth sucks.
Feb 22 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 21 February 2012 at 00:19:47 UTC, Jonathan M Davis 
wrote:
 In my experience, you only run into weird terminal nonsense
 with old computers or maybe sometimes with ssh. Other than
 that, there aren't any weird problems like that.

It happens a lot if you use a lot of different unixes. ssh from Linux into BSD, for example, and it is easy to hit these incompatibilities.
Feb 20 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 12:21:33AM +0100, Adam D. Ruppe wrote:
 On Monday, 20 February 2012 at 23:12:36 UTC, James Miller wrote:
Windows has not, historically, been a pleasant platform to develop
lower-level code for

I couldn't disagree with that more, especially if you're comparing to something like linux. The linux console is a big pain.

Weird. I guess I must be a very strange person, because I find that my productivity soars at the command-line, but when I'm forced to used Windows, productivity drops to 20% because of all that keyboard-to-mouse switching and clicking through endless layers of menus just to get one thing done. But to each his own. At my previous job I spent 2 hours wrestling with MS Word to produce a half-page document with the right formatting, yet "normal" people can do that in 10 minutes (because they don't care about the ugly formatting). In that same 10 minutes I can produce a 2 page document in LaTeX with far superior formatting. I guess that makes me a weirdo. :-) T -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr
Feb 20 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.740.1329784653.20196.digitalmars-d puremagic.com...
 On Tue, Feb 21, 2012 at 12:21:33AM +0100, Adam D. Ruppe wrote:
 On Monday, 20 February 2012 at 23:12:36 UTC, James Miller wrote:
Windows has not, historically, been a pleasant platform to develop
lower-level code for

I couldn't disagree with that more, especially if you're comparing to something like linux. The linux console is a big pain.

Weird. I guess I must be a very strange person, because I find that my productivity soars at the command-line, but when I'm forced to used Windows, productivity drops to 20% because of all that keyboard-to-mouse switching and clicking through endless layers of menus just to get one thing done.

I literally grew up on command-lines[1]. But despite that, I still much prefer GUIs for anything a GUI reasonably works for: Like file browsers, DB admin, manual DB queries, debuggers, Tortoise*, etc. (although for web server configuration I've come to vastly prefer config files - MUCH easier to remotely manage, plus the settings for files/paths are necessarily tied to the file/path *name*, not the physical file, so you don't kave to keep messing with them every time something's moved/renamed/deleted/recreated) When I'm on Linux, I've come to do most things on the command line just because 1. Many things still can only be done on the cmd line, and 2. Linux file managers suck about as much as the Windows command line. I'm proficient with bash, and I do love it as far as command lines go (And damn near anything can be scripted, which is fantastic), but I hate using it for file manipulation - just seems really clumsy compared to a *good* GUI file manager (which I've yet to find on Linux). Although the autocomplete *is* a huge help. Although that said, even the Windows file manager has been plummeting downhill ever since Vista. I don't know wtf MS has been thinking. Keyboard/mouse switching comes pretty naturally to me. Part of it's probably years of practice, and the other part is that I use trackballs which tend to mostly stay put. [1] First AppleSoft BASIC and occasionally the built-in memory-editor and AppleSoft Logo. Later, MS-DOS 6-ish and occasionally gwbasic (normally used QBASIC instead, though)
Feb 21 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 06:22:25PM -0500, Nick Sabalausky wrote:
[...]
 That hadn't occurred to me. Thanks. Normally, the only time I use
 fg/bg is if I try to cancel something with Ctrl-blah and it suspends
 the process instead of stopping it. So then I "fg [whatever num]" and
 either try a different key combo or let it finish.

fg/bg is the best thing on earth since sliced bread. Well, to me. :) It lets me fire up my (text-based) mail client, read mail halfway, find someone mentioning an obscure library function, press ctrl-Z to suspend to mail client, `man obscure_function` to find out on earth they're talking about, then fg to continue reading mail. Or, I'm doing some heavy D coding (yeah!), run into some syntax I'm unsure about, so ctrl-Z to suspend vim, pushd /tmp, vim test.d, write some test code, ctrl-Z the second vim, run gdc/dmd to see if a particular construct compiles and does what I think it does, if not, fg, edit more code, ctrl-Z, recompile, whoopie, it works now, fg, :q! to exit 2nd vim, now fg %1 to get back to 1st vim, continue heavy D coding. And somewhere in the midst of all that, the background music gets too loud, so ctrl-Z to suspend whatever I was doing, run alsamixer to adjust volume, quit, fg to resume what I was doing. (Or do the same thing when music is finished, run mplayer to start new music, etc..) All this, within a single rxvt terminal. I don't even have to switch to a different window or take my hands off the keyboard. On a good day, I can have up to 4 or 5 backgrounded processes, mostly vim sessions with heavy D coding, perhaps a mail client, a 2nd mail client in the middle of a long reply, a pager viewing an open manpage, etc.. Yeah. I'm such an ubergeek. :P I only actually need more than one terminal when dealing with spammy programs, like long-running large compile jobs, or mplayer (unless I silence it with `echo -n | mplayer ... >/dev/null 2>&1&` -- the echo is there otherwise mplayer insists on reading stdin from the terminal, which when it's backgrounded causes it to get suspended by SIGTTOU -- yet another gratuitous tty annoyance inherited from the old days). Or when I lose my geekiness and actually switch to a GUI browser window. :P
 But still, I'd venture to say that probably 99.9% of the times you
 launch a gui app from the command line, you don't want, or at least
 don't need, it to be blocking or spamming the console. It'd be nice if
 it could do like windows and detect "gui or cmdline" so it can
 automatically do the right thing without the user coddling it.
 Unfortunately I'm not sure that's possible since I don't think Linux
 binaries are flagged as "cmdline or gui" like in windows. It just
 either calls some GUI apis or it doesn't.

Yeah. And worse yet, I've actually encountered GUI Linux apps that expect input from stdin. I'm not kidding. As they say, fact is stranger than fiction.
 That reminds me of another thing (yea, I know I sounds like I'm just
 ranting on and on about Linux, but I *do* rather like it overall):
 What the hell is up with this "sudo" vs "gtksudo/kdesudo" shit? I
 understand that it's somehow necessary for the
 permissions/process-owner stuff to all be right, but why should *that*
 be necessary?

Because Unix was designed with multiple users in mind. It has to ensure that users don't stomp all over each other.
 The whole Unix philosophy is orthogonality, one tool to do one task
 well, no duplicated functionality for slightly-different use cases.
 The whole "sudo" vs "gtksudo/kdesudo" thing seems to be some sort of
 big ugly hack.

It's to prevent people from doing foolish things like logging in as root and doing everyday tasks as root, just because one or two commands *might* require root privileges. It's convenient, it's like Windows and DOS where you can do pretty much anything without this troublesome protection thing. Like install programs and stuff. Until one day you want to remove everything from the current directory but instead type this as root: rm -rf . /* (The space between . and / is a typo... that you will regret for the rest of your life.) In the old days, you'd just be restricted to a non-root user, so certain programs won't run (they need root access to, e.g., access a certain hardware). You have to `su - root`, type in root's password, run the program, then exit from root. Very tedious. Sudo lets you use your *user* password and runs exactly a single command -- the one command that actually *needs* root access. Everything else stays in non-root space, so even if you screw up and destroy your entire home directory, the system itself is still intact and you can still recover. Whereas the above command, running as root, will likely cripple your system in the few seconds before you notice something is wrong, and quite possibly ruin your entire day (and the next 2 days) in the following few seconds before you react and hit ctrl-C. Depending on what order rm tries to delete stuff, by the time you stop it there may not be anything left in /bin or /usr/bin, and then you'll have to be macho and use echo commands to recreate binary files. :P :P :P T -- This sentence is false.
Feb 21 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.826.1329869015.20196.digitalmars-d puremagic.com...
 On Tue, Feb 21, 2012 at 06:22:25PM -0500, Nick Sabalausky wrote:
 [...]
 That hadn't occurred to me. Thanks. Normally, the only time I use
 fg/bg is if I try to cancel something with Ctrl-blah and it suspends
 the process instead of stopping it. So then I "fg [whatever num]" and
 either try a different key combo or let it finish.

fg/bg is the best thing on earth since sliced bread. Well, to me. :) It lets me fire up my (text-based) mail client, read mail halfway, find someone mentioning an obscure library function, press ctrl-Z to suspend to mail client, `man obscure_function` to find out on earth they're talking about, then fg to continue reading mail.

Yea, see I think the reason I almost never use it is because I'm still not used to having it available. "When all you have is a hammer..." So I instinctually just fire up another window, another connection, or another whatever, whenever I need to multitask. But now that you mention it, I can definitely think of times when I could really make use of it. For instance, when browsing through the man page describing all the args for a command I'm using. Not sure if I'll actually end up kicking the habit of avoiding it though. I've spent years on systems (including Windows) with multiple desktops available in the taskbar, and I always ended up just using one of the desktops. I always liked the idea of multiple desktops, but using more than one just meant spending more mental effort on organization and "What the hell desktop did I leave that window on??". heh :)
 Yeah. And worse yet, I've actually encountered GUI Linux apps that
 expect input from stdin. I'm not kidding. As they say, fact is stranger
 than fiction.

Eww. That's just...wow.
 The whole Unix philosophy is orthogonality, one tool to do one task
 well, no duplicated functionality for slightly-different use cases.
 The whole "sudo" vs "gtksudo/kdesudo" thing seems to be some sort of
 big ugly hack.

It's to prevent people from doing foolish things like logging in as root and doing everyday tasks as root, just because one or two commands *might* require root privileges. It's convenient, it's like Windows and DOS where you can do pretty much anything without this troublesome protection thing.

Oh, no, that's not what I meant. I understand the need for sudo, and I'm totally in favor of it. What bugs me is why we *also* have "gtksudo/kdesudo". Ie: $sudo apt-get install foobar versus: $kdesudo kate /etc/some-system-config-file & When you run a commandline tool with root privileges, you use "sudo". *But*, when you run a GUI app, you're supposed to use "kdesudo" or "gtksudo" (or is it "gsudo"?) instead. Apperently, launching a GUI app via "sudo" causes some ownership or permissions or something to be wrong even though it usually apears to work fine (I don't understand the details). That's what I mean: Shouldn't there just be *one* "sudo" that works properly for launching *both* GUI and commandline apps? Shit, this whole thread is too damn addictive!
Feb 21 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 06:49:45PM -0500, Nick Sabalausky wrote:
[...]
 I think that globbing should be done explicity by the app, *but* for
 apps that don't play ball you should be able to *explicitly* do it at
 the command line. Example:
 
 $someutil *.txt foo.html
 ERROR: Can't find file '*.txt'
 $glob *.txt
 'hello.txt' 'Modern File Name.txt' 'another.txt'
 $someutil `glob *.txt` foo.html
 Processing hello.txt...done
 Processing Modern File Name.txt...done
 Processing another.txt...done
 Processing foo.html...done

Hmm. I like that idea: have the shell *not* interpolate things by default, unless you explicitly say to do so. So by default typing: rm *.txt will pass "*.txt" to rm as a single argument, whereas: # Not real syntax: rm `*.txt` will expand "*.txt" as a glob and pass the result to rm. [...]
 Which brings up another little nitpick: When bash displays a prompt,
 it should first check to see if the last char output was a newline. If
 not, it should...ADD ONE!

Yeah I agree with that one. Unfortunately I don't think it can tell, because the previous command writes to stdout directly (it doesn't go through bash -- else it's be too inefficient, you'd have processes copying stuff from each other all over the place). The terminal doesn't let you ask "what was the last char sent to you?". Having said that, though, the terminal *does* have an escape sequences (yeah, ugh) that bash *could* use to find out where the cursor is, and if it's not at column 0, insert a newline. Unfortunately, us old hands have gotten so used to this misbehaviour that we actually *use* it to detect whether something has a newline at the end or not. Another of those historical accidents calcified before it can be disinfected. T -- BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL
Feb 21 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.829.1329869699.20196.digitalmars-d puremagic.com...
 On Tue, Feb 21, 2012 at 06:49:45PM -0500, Nick Sabalausky wrote:
 [...]
 I think that globbing should be done explicity by the app, *but* for
 apps that don't play ball you should be able to *explicitly* do it at
 the command line. Example:

 $someutil *.txt foo.html
 ERROR: Can't find file '*.txt'
 $glob *.txt
 'hello.txt' 'Modern File Name.txt' 'another.txt'
 $someutil `glob *.txt` foo.html
 Processing hello.txt...done
 Processing Modern File Name.txt...done
 Processing another.txt...done
 Processing foo.html...done

Hmm. I like that idea: have the shell *not* interpolate things by default, unless you explicitly say to do so. So by default typing: rm *.txt will pass "*.txt" to rm as a single argument, whereas: # Not real syntax: rm `*.txt` will expand "*.txt" as a glob and pass the result to rm. [...]
 Which brings up another little nitpick: When bash displays a prompt,
 it should first check to see if the last char output was a newline. If
 not, it should...ADD ONE!

Yeah I agree with that one. Unfortunately I don't think it can tell, because the previous command writes to stdout directly (it doesn't go through bash -- else it's be too inefficient, you'd have processes copying stuff from each other all over the place). The terminal doesn't let you ask "what was the last char sent to you?". Having said that, though, the terminal *does* have an escape sequences (yeah, ugh) that bash *could* use to find out where the cursor is, and if it's not at column 0, insert a newline. Unfortunately, us old hands have gotten so used to this misbehaviour that we actually *use* it to detect whether something has a newline at the end or not. Another of those historical accidents calcified before it can be disinfected.

Windows's cmd.exe always inserts a newline right before a command prompt. So you get the best of both worlds. Only issue is you end up with excess newlines. For example, you get: C:\>echo Hello > filea.txt C:\>echo Hello > fileb.txt C:\> C:\>cd foo C:\foo\> C:\foo\> Instead of: ~$echo Hello > filea.txt ~$echo Hello > fileb.txt ~$ ~$cd foo ~/foo$ ~/foo$ But maybe that's not quite as bad? Come to think of it, bash should be able to do the same thing if you add a newline to the beginning of $PS1... Ha! It does work! Boy is that funny, it makes bash look like windows :) That's just weird. But, of course, it does mean a lot of extra blank lines. Which is ugly if you're doing a lot of no-output commands. But then, it's also much easier to read when there's a lot of heavy-output commands. It's a tradeoff :/
Feb 21 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.829.1329869699.20196.digitalmars-d puremagic.com...
 On Tue, Feb 21, 2012 at 06:49:45PM -0500, Nick Sabalausky wrote:
 [...]
 I think that globbing should be done explicity by the app, *but* for
 apps that don't play ball you should be able to *explicitly* do it at
 the command line. Example:

 $someutil *.txt foo.html
 ERROR: Can't find file '*.txt'
 $glob *.txt
 'hello.txt' 'Modern File Name.txt' 'another.txt'
 $someutil `glob *.txt` foo.html
 Processing hello.txt...done
 Processing Modern File Name.txt...done
 Processing another.txt...done
 Processing foo.html...done

Hmm. I like that idea: have the shell *not* interpolate things by default, unless you explicitly say to do so. So by default typing: rm *.txt will pass "*.txt" to rm as a single argument, whereas: # Not real syntax: rm `*.txt` will expand "*.txt" as a glob and pass the result to rm.

I've just thought of (ie, gotten bit by) another thing that would be nice about having the commands do their own globbing: If the applications glob on their own insted of the shell, then for safety they can choose to restrict the number of file args they take to whatever makes sense for their own individual purpose. For example, suppose you want to delete everything inside a given subdirectory (but keep the directory itself). So then you (mis)type: $rm somedir/ * -rf Note the subtle space before the "*". I just did that by mistake earlier today, and the damage set me back a few hours (could have been much, much worse, though). I don't think there's much, if anything, that can realistically be done to protect against that right now. At least without getting really hacky. But, if rm was expected to do its own globbing instead of the shell doing it, then rm could say: "Ok, it only makes sense for you to give me one file/path at a time. Want more? Run me multiple times or use a glob pattern (or hell, a regex pattern, or use a special explicit 'accept multiple paths' mode, etc)." Then: $rm somedir/ * -rf ERROR: rm only takes one path at a time $rm somedir/* -rf # ok $rm somedir/ -rf # ok $rm * -rf # ok With the shell doing the expansion, that sort of thing isn't even possible. Works with other stuff too: $cp a b c ERROR: You gave me a source path and a destination path, but then you gave me *another* path! What the hell you expect *me* to do with it?
Feb 26 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 22 February 2012 at 00:03:35 UTC, H. S. Teoh wrote:
 It lets me fire up my (text-based) mail client

mutt???? I switched to mutt from the terrible webmail in... 2007 I think. Rarely look back (only when I need to view images when on a separate computer). I handle 200-300 emails a day. I don't think I could handle it if not for how awesome mutt is.
 music is finished, run mplayer to start new music, etc..)

mplayer rox. I also use a play script that runs sox (or timidity) for simple files. gui music sux. I use a screen session for this stuff though. window 0: the background noise controller window 1: mutt window 2: alsamixer window 3: random notes to self for later Usually, I only two two at a time. C-a a is the best thing ever. Then I use a separate screen for work things. Now, here's something cool: from my laptop, running Windows 7, I use putty to connect to the house. But, here's what I did: it automatically runs screen, with the escape set to s, rather than a, and a fixed session name. First off, C-s is easier to hit on the laptop than C-a since the Fn key is on the far left, instead of ctrl. So it is a more natural action anyway. Aaaand I can run other screens inside! screen -d -r ffmp3 # the one with mutt, etc C-s c screen -d -r work Now, I can C-s s to swap between the two things... and C-a a to swap sub tasks. Nested screens is pretty amazing. And that automatic session means I can open and close it at will, picking up exactly where I left off every time.
Feb 21 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 03:44:33AM +0100, Adam D. Ruppe wrote:
 On Wednesday, 22 February 2012 at 02:03:58 UTC, H. S. Teoh wrote:
Hmm. Let's implement shell utilities in D! (Pointless, yeah, but a
fun exercise to see how much cleaner D code can be -- if you've

I'm sooo tempted again. Though, I don't really like shell utilities.... I'd want many of them to be accessible through api, and at that point, might as well just do them all as built ins. I guess if there's another file available, we can call it instead to allow easy replacement, but I just think making the shell there as a library is a really nice thing.

Totally!! Instead of 500 standalone shell utils, each with the same old boilerplate command-line parsing, each of which requires fork() and exec() to use, why not make their functionality directly available as a library? It's clear that the trend of computing is toward automation anyway. In the long-term, it isn't so much about how l337 your CLI skills are in stringing 20 different commands together in one line, it's about how the commonly-used functionality in these 20 commands can be reused by *programs* that call common library functions. Shell-scripting is only a temporary solution; all those fork/exec calls do add up. This reminds me of a funny incident at my first job, where there was a shell script that a coworker was using to generate some reports. It worked fine up till that point, since it had only been used for relatively small datasets. That day, someone tried to generate a rather large report, and it was taking forever. In fact, it took >48 hours to complete. When the prospect arose that we might need to generate similar reports again, they approached me to ask if I could do something about the obvious performance problem of this script. Turns out the script was really simple, but had to do some amount of calculations, which it did using code along these lines: while [ ! -z "$still_more_data" ]; do $data=`cat $inputfile | sed -ne${linenum}p` $input=`grep $fieldname $data` $result=`expr $result + $input` ... done There were several *nested* loops like that. I didn't analyze it much further, but it must had been something like O(n^6) complexity or something insane like that, due to cat'ing the (same) input file umpteen times, grepping each line multiple times, saving results to temporary files and then grepping *those* files (multiple times), and spawning who knows how many subprocesses along the way. I rewrote the miserable thing in Perl in a couple of hours, and the Perl script took 2 minutes to produce the report. :-P So yeah. A shell utils library would definitely be a big plus.
 class ShellOperations { /* methods here */ }
 then use compile time reflection to build your map for the
 command line processing....
 
 Our D shell could be just one program.

Yeah, a shell with many commands built-in is a good thing, IMHO. I had to rescue a remote server using only echo commands (one of the only commands built into bash). If rm, ls, and friends had been part of bash instead of needing a fork() and exec() followed by dynamic linking every single time I typed a command, things would have gone a *lot* smoother.
 though tbh if I was doing a shell, I'd kinda want to do
 a terminal replacement too. But, I don't see myself leaving
 xterm and rxvt. Nor putty.

If you were savvy (or crazy) enough, you could always try your hand at writing termcap/terminfo entries... :P
 idk, should probably limit the scope a bit just to make it
 realistic to finish. Use gnu readline too and piggyback on
 that pretty nice function for history, editing, completion,
 etc.

True. For a first stab at it, I wouldn't go crazy with trying to rewrite the terminal. Get some working code first, that's actually usable at the basic level, then we can get fancy. Nothing more discouraging than a grandiose uber-design of a utopian system that's sitting in the source tree with thousands of lines already written but nothing actually running, and nothing runnable for the foreseeable future.
 Actually that makes it fairly doable as a weekend project.

Go for it!
Only? Heh... when I was young and foolish, I wanted to trump Linus
and write my own kernel.

I've tried it before.... but it is terribly boring. As cool as it is to say "every line of code on that box is mine and mine alone", that's all it is good for imo: bragging.

I dunno, I've always loved low-level coding. I used to keep an eye on Hurd, because the prospect of moving most kernel functionality into userspace appealed to me very much. But nowadays I just don't have the time for highly time-consuming projects like that.
 The interesting stuff is all user territory.

Depends. Linux driver development is a constantly growing area, if you're into that sorta thing. You won't have fancy graphical sfx to show for it (unless you're into video driver development), but you'll have the great satisfaction of knowing that you made that particularly stubborn piece of hardware actually work nicely with Linux.
My concept of shell is to make it a very thin (but scriptable) layer
over actual syscalls, so you could do something like:

Eeeeeeh.... at that point, you might as well just write your commands in C (or D).

Well, yes and no. The point was more to play around with syscalls interactively. Of course, I also have other shell ideas on the other extreme of the spectrum, where it's sorta like interactive D, except with a filesystem navigation / file searching / file manipulation bent, rather than trying to write a compilable app. (Though it wouldn't hurt if scripting in such a shell actually was the same as writing an actual D program. :P)
 I actually like bash a lot... but only for 1-3 line things.
 Bigger than that, and screw it, I'd rather just write C/D.
 bash is a huge pain to get anything done for > 3 lines...

For that I use perl.
 But for those 1-3 line things, it is really nice. And, since
 it is a command line shell, that's exactly what it should be
 optimizing!

I can't say I'm too fond of bash syntax. I guess it does the job, and is relatively expressive, so it's OK. But I'm a programmer-head, so I tend to turn everything into a programming language. :P (Or Turing tarpits on bad days.) On another note, in my first job we had a temp consultant one time, who had the uncanny ability to write insanely-long bash commands that Just Work(tm). It's like he thinks in bash, and these insanely elaborate commands just flow out of him. They are always on a single line, but can involve 10-15 different programs in a long chain. They always work on first try, and work wonders every time. To this day we still don't know how he does it. T -- Why do conspiracy theories always come from the same people??
Feb 21 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
I started the dshell just to waste a little time:

http://arsdnet.net/dcode/dshell.d

         dmd dshell.d -L-lreadline -L-lncurses

It doesn't do much here, but there's a few things I think
are cool:

1) D reflection rox. You can write D functions with simple
arguments and it works basically. I want to detect bitfield
enums to automatically do -flags too.

2) Your functions can return whatever, and it is wrapped in
a runtime polymorphic range.

If you just want strings, you can do ProgramDataByLine(input).

If you want something fancier, you can use 
originalProgramData!Type
to fetch out the original input range.


The syntax is so far just the basics... calling functions
and pipes.



but hey its kinda cool already.
Feb 22 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 24, 2012 at 07:19:33PM +0100, Adam D. Ruppe wrote:
 On Friday, 24 February 2012 at 17:54:47 UTC, H. S. Teoh wrote:
You could just pad the unused space with blank pixels.

whoa, make a tile based system, like the NES. There's a private use area in unicode, 16 bits of space I think.

Heh, I was thinking of exactly the same thing, the unicode PUA. Great minds think alike. :) The PUA is actually 17 bits of space, U+F0000 -> U+10FFFF. There's also a smaller stretch in the BMP, from U+E000 -> U+F8FF, which might be useful if you want to stick with 16-bit characters.
 You could define a tile set to use that, or a simple bitmap format,
 but it isn't enough room to do on demand tiles I think.

 Imagine this though, your terminal lets the app define new characters,
 in color. The protocol might be an escape sequence then you go ahead
 and write out an image using whatever format (xpm or base64 png -
 something you can easily enough represent as text.)
 
 Then, you overwrite a private use character. You can then write
 that character to display the custom glyph.
 
 Now, you treat it just like any other character for writing,
 scrolling, read back, etc. Mixes right in with text.

I like it. Reminds me of those old DOS games that used to do that, except they have only 8 bits of space, so only trivial things could be done. :)
 Now, you won't be able to just "cat image.png", but you could
 write a cat that does it. Define a tileset for a line, write
 it out, repeat and let it scroll to show the whole image.

But why constrict yourself needlessly? Unicode already has double-width characters, like pretty much the entire CJK block. Some terminals/apps already handle that (e.g. rxvt/vim on a CJK file). Nothing stops you from assigning an entire bitmap to a private use character. Call it multiwidth-multiheight. Now you have lots more room in the character encoding for reusable bitmaps. :P Or if multiheight is too messy to implement, at least multiwidth will allow you to represent an entire bitmap row as a single PUA character. So a large PNG will just be a linear sequence of PUA characters representing rows in the image. T -- No! I'm not in denial!
Feb 24 2012
prev sibling parent James Miller <james aatch.net> writes:
On 23 February 2012 15:56, Adam D. Ruppe <destructionator gmail.com> wrote:
 I started the dshell just to waste a little time:

 http://arsdnet.net/dcode/dshell.d

 =C2=A0 =C2=A0 =C2=A0 =C2=A0dmd dshell.d -L-lreadline -L-lncurses

 It doesn't do much here, but there's a few things I think
 are cool:

 1) D reflection rox. You can write D functions with simple
 arguments and it works basically. I want to detect bitfield
 enums to automatically do -flags too.

 2) Your functions can return whatever, and it is wrapped in
 a runtime polymorphic range.

 If you just want strings, you can do ProgramDataByLine(input).

 If you want something fancier, you can use originalProgramData!Type
 to fetch out the original input range.


 The syntax is so far just the basics... calling functions
 and pipes.



 but hey its kinda cool already.

And I've been playing with trying to write my own terminal emulator. I actually kinda have one working, in C. I just need to wrap all the C code in functions and do all the interesting stuff in D. The terminal doesn't support most (any) terminal codes, in either direction it also doesn't do any scrolling, so if you hit the end of the window, you're kinda screwed... Its more a proof-of-concept than anything actually usable. But I have plans for it, including some cool graphical stuff. I'm using clutter to render everything, so I can do all sorts of things with it, but to start with, I'd like to be able to display pictures inline, so you can do `cat my_pic.jpg` and rather throwing masses of garbage at you, it renders the picture, I might have to write my own cat to do so however... -- James Miller
Feb 22 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 21 February 2012 at 00:38:46 UTC, Andrei Alexandrescu 
wrote:
 ssh into Windows and... well last time I did it it was like 
 "welcome to Hell".

Oh, certainly!
Feb 20 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 21 February 2012 at 00:37:33 UTC, H. S. Teoh wrote:
 Weird. I guess I must be a very strange person, because I find 
 that my productivity soars at the command-line

Me too. Command line rocks, and bash is a fine shell. (csh sucks though, why its the default on so many bsds is beyond me.) What I'm talking about here is the underlying technology and ease of programming. It isn't difficult to get a compiler on Windows and write code. You can use Visual Studio, or notepad, or anything in between. You can write a lot of code easily, from 16 bit DOS programs (well, not anymore on 64 bit, but you could for a long, long time) up to gui apps, including doing console apps that have an api similar to vga text hardware. On Linux, you have to worry about terminal escape sequences, libc incompatibilities, and all kinds of other stuff to write similar programs. Remember though, that this isn't about the shell or userland. I really like the Linux command line (though it isn't perfect... ever gotten "command line too long" due to how * is expanded by the shell? Ugh.). But anyway I really like it, but the operating system isn't any easier to program for. Indeed, if you want to distribute your app, it is a lot harder due to compatibility. Windows apps tend to just work.
Feb 20 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 12:39:01AM +0100, Adam D. Ruppe wrote:
[...]
 Yeah, though I've only seen it suggested for daemon like
 programs... I think you're the first person who I've seen
 suggest it for gui apps too.
 
 Not a bad idea.

Perhaps I'm just dreaming, but I *think* I've seen one GUI app that actually does that. But I could be wrong. T -- Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis
Feb 21 2012
prev sibling parent James Miller <james aatch.net> writes:
On 22 February 2012 13:06, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 On Wed, Feb 22, 2012 at 12:39:01AM +0100, Adam D. Ruppe wrote:
 [...]
 Yeah, though I've only seen it suggested for daemon like
 programs... I think you're the first person who I've seen
 suggest it for gui apps too.

 Not a bad idea.

Perhaps I'm just dreaming, but I *think* I've seen one GUI app that actually does that. But I could be wrong. T

GVim does it, its amazing, since I normally start it from the terminal and chronically forget to use '&'. The one downside of this is when you /want/ the blocking behaviour (git editor for example), gvim gets around this by providing a '-f' flag that tells it not to fork. I wish all GUI programs provided that kind of feature set, but I concede that GVim is made /for/ programmers and launching from the terminal is a common use case, as is wanting to use it as a drop in replacement for vim, so here we are. -- James Miller
Feb 21 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Feb 20, 2012 at 06:38:47PM -0600, Andrei Alexandrescu wrote:
 On 2/20/12 6:25 PM, Adam D. Ruppe wrote:
On Tuesday, 21 February 2012 at 00:19:47 UTC, Jonathan M Davis wrote:
In my experience, you only run into weird terminal nonsense
with old computers or maybe sometimes with ssh. Other than
that, there aren't any weird problems like that.

It happens a lot if you use a lot of different unixes. ssh from Linux into BSD, for example, and it is easy to hit these incompatibilities.

ssh into Windows and... well last time I did it it was like "welcome to Hell".

Heh, I didn't know you could ssh into Windows. Now I know never to actually do it. :-) T -- "Life is all a great joke, but only the brave ever get the point." -- Kenneth Rexroth
Feb 20 2012
parent "Paulo Pinto" <pjmlp progtools.org> writes:
You need to enable it.

"H. S. Teoh"  wrote in message 
news:mailman.748.1329787800.20196.digitalmars-d puremagic.com...

On Mon, Feb 20, 2012 at 06:38:47PM -0600, Andrei Alexandrescu wrote:
 On 2/20/12 6:25 PM, Adam D. Ruppe wrote:
On Tuesday, 21 February 2012 at 00:19:47 UTC, Jonathan M Davis wrote:
In my experience, you only run into weird terminal nonsense
with old computers or maybe sometimes with ssh. Other than
that, there aren't any weird problems like that.

It happens a lot if you use a lot of different unixes. ssh from Linux into BSD, for example, and it is easy to hit these incompatibilities.

ssh into Windows and... well last time I did it it was like "welcome to Hell".

Heh, I didn't know you could ssh into Windows. Now I know never to actually do it. :-) T -- "Life is all a great joke, but only the brave ever get the point." -- Kenneth Rexroth
Feb 21 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Feb 20, 2012 at 06:44:16PM -0600, Andrei Alexandrescu wrote:
 On 2/20/12 6:41 PM, Adam D. Ruppe wrote:
On Tuesday, 21 February 2012 at 00:38:46 UTC, Andrei Alexandrescu wrote:
ssh into Windows and... well last time I did it it was like "welcome
to Hell".

Oh, certainly!

Rats. I was hoping the boys in Redmond have improved the situ since.

Why would they, though? AFAICT the entire Windows system was designed to be centered on the GUI. I'm sure they would recommend using some kind of remote desktop instead of ssh for remote administration. It would fit better into the Windows way of doing things, and avoid a lot of the pain that comes when you try to *not* do things according to Windows' way. (Yes I was stupid enough to try that before. Never dared try it again.) T -- If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton
Feb 20 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 02:00:20AM +0100, Adam D. Ruppe wrote:
 On Tuesday, 21 February 2012 at 00:37:33 UTC, H. S. Teoh wrote:
Weird. I guess I must be a very strange person, because I find that
my productivity soars at the command-line

Me too. Command line rocks, and bash is a fine shell. (csh sucks though, why its the default on so many bsds is beyond me.)

Heh. I was enamored of tcsh for a great many years, possibly a decade, until I finally decided bash's nice features outweighed its annoying parts.
 What I'm talking about here is the underlying technology and ease of
 programming.
 
 It isn't difficult to get a compiler on Windows and write code. You
 can use Visual Studio, or notepad, or anything in between.

Same with Linux, I thought? Although I mainly just use vim for programming, so maybe I'm unaware of the full situation.
 You can write a lot of code easily, from 16 bit DOS programs (well,
 not anymore on 64 bit, but you could for a long, long time) up to gui
 apps, including doing console apps that have an api similar to vga
 text hardware.
 
 On Linux, you have to worry about terminal escape sequences, libc
 incompatibilities, and all kinds of other stuff to write similar
 programs.

Terminal escape sequences?! You should be using libcurses or libncurses. No wonder you had a bad experience. :) But I agree with you though, that libc incompatibilities are really really REALLY annoying. Like snprintf(NULL, 0, fmt, ...) working like a charm in one libc, and segfaulting or returning garbage values on other libc's. The C99 spec *does* specify how it should behave, but that doesn't help when the libc is not 100% compliant. Besides, some parts of C99 are really stupid anyway, like the half-hearted part with wchar_t. Then you have libc's that are missing some convenient functions which you then proceed to define, only to discover it fails to compile elsewhere 'cos it conflicts with the system-defined function. That's why I'm liking D a lot, in spite of it still being under development and having nasty compiler/library bugs every now and then. :) For all its current flaws, D does a wonderfully better job than C/C++ in so many places.
 Remember though, that this isn't about the shell or userland. I really
 like the Linux command line (though it isn't perfect... ever gotten
 "command line too long" due to how * is expanded by the shell? Ugh.).

Yeah I remember that. I thought they've since fixed it, though. That's more a bash limitation than anything, AFAIK. Besides, what *were* you trying to do with such a long command-line anyway? :-)
 But anyway I really like it, but the operating system isn't any easier
 to program for. Indeed, if you want to distribute your app, it is a
 lot harder due to compatibility.

Yeah, Unixland really works best with the "here's the source code, compile it yourself" model, rather than with the Windows "here's the binary executable" model. Gentoo's emerge is a step closer to making it more accessible to end-users (i.e. non-programmers who don't know what "compile" means), but still, compiling source code isn't always an option. Most distros do distribute prebuilt binaries, but if your app isn't part of the distribution, things get tough. You have to set up your own RPM/deb repository and have complicated instructions for people to set things up so that the right version is downloaded, etc.. Not very friendly to end-users who want things to Just Work.
 Windows apps tend to just work.

Generally true. Though when they fail, they tend to fail in rather horrible ways. I remember long frustrating nights of trying to make two apps that require conflicting DLLs install properly without trampling all over each other and deleting system files that crash the entire system. And this was on my wife's laptop with a relatively small number of programs installed, and which is only used for limited things like email, browsing, etc.. I can only imagine the horror it in large, non-trivial installations. But then again, I *did* also have to deal with having to repair a remote Linux server whose dynamic linker broke, causing basic commands like ls, cp, chmod, to be completely non-functional. In fact, *nothing* worked except that last remote login running bash. In the end I had to use bash's built-in echo command to recreate a statically-linked busybox binary via copy-n-pasting over the terminal, in order to get things back into working condition again. (Yeah. Definitely not for the faint of heart.) So I couldn't tell you which is worse. :) At least on Linux you actually have a fighting chance of fixing the problem, whereas on Windows you most probably have to just reformat and reinstall the entire system. T -- Acid falls with the rain; with love comes the pain.
Feb 20 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 01:21:41AM +0100, Adam D. Ruppe wrote:
 On Wednesday, 22 February 2012 at 00:03:35 UTC, H. S. Teoh wrote:
It lets me fire up my (text-based) mail client

mutt????

Yep!
 I switched to mutt from the terrible webmail in... 2007 I think.
 Rarely look back (only when I need to view images when on a
 separate computer).

Webmail gives me acne. For a while at my job before I figured out how to download work email onto my Linux development box, I had to use webmail. No threading, poor folder support, flaky search box, default HTML formatting (ugh!), it's like Windows 3.0 reincarnated. Eww.
 I handle 200-300 emails a day. I don't think I could handle
 it if not for how awesome mutt is.

Yeah, I saw several people remarking about how unmanageably huge the Exceptions thread is, but mutt handles it just fine. In fact, without mutt, I would've lost track of where the discussion was going a long time ago. (Although, it *is* starting to get to the point where the threading lines are going past the right edge of the screen...) Come to think of it, perhaps that's why people started rehashing the same arguments over and over after a while, 'cos without proper threading support in your mail client, it's just impossible to keep track of who is replying to what, much less keep all the different conversations straight. Years ago I used to be subscribed to a truckload of opensource mailing lists. On top of that, if I turned off spamassassin, I'd get about 200 spams a *day*. (My email address is too public, unfortunately.) Only mutt could handle that sort of mail load. I used to use pine, but it had no threading, which especially sucked for dealing with mailing lists: there was no way to delete-entire-thread without manually pressing D 300 times. IIRC it was mailing lists that convinced me to switch to mutt. Never looked back since.
music is finished, run mplayer to start new music, etc..)

mplayer rox. I also use a play script that runs sox (or timidity) for simple files. gui music sux.

Yeah, it's just audio, why does it need a GUI interface, right? :) If it was video that'd be a different story. [...]
 Aaaand I can run other screens inside!

Nice. [...]
 Nested screens is pretty amazing. And that automatic
 session means I can open and close it at will, picking
 up exactly where I left off every time.

Nice, I should set that up sometime. I have screen running on a persistent session, but if I need to reconnect, I have to start over. It'd be cooler if it was *always* persistent unless the machine itself went down. Cool. T -- "Hi." "'Lo."
Feb 21 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 07:27:41PM -0500, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.826.1329869015.20196.digitalmars-d puremagic.com...

 fg/bg is the best thing on earth since sliced bread. Well, to me. :)

 It lets me fire up my (text-based) mail client, read mail halfway, find
 someone mentioning an obscure library function, press ctrl-Z to suspend
 to mail client, `man obscure_function` to find out on earth they're
 talking about, then fg to continue reading mail.

Yea, see I think the reason I almost never use it is because I'm still not used to having it available. "When all you have is a hammer..." So I instinctually just fire up another window, another connection, or another whatever, whenever I need to multitask.

It goes the other way too. When I use my wife's Windows laptop, I keep trying to ctrl-Z to background what I was doing, and I keep wondering, how do I get the list of backgrounded tasks so I can get back to that other thing I was trying to do?? :P Scarily enough, sometimes ctrl-Z actually works... 'cos I'm usually on putty when using Windows. :P [...]
 Not sure if I'll actually end up kicking the habit of avoiding it
 though.  I've spent years on systems (including Windows) with multiple
 desktops available in the taskbar, and I always ended up just using
 one of the desktops. I always liked the idea of multiple desktops, but
 using more than one just meant spending more mental effort on
 organization and "What the hell desktop did I leave that window on??".
 heh :)

Yeah I tried multiple desktops for a while, but after a while it was just too hard for my little brain to keep track of where things are. Some WMs try to help by displaying a little desktop map in the corner, but it doesn't help when you have large windows obscuring small ones completely. Eventually I gave up and went the other extreme: ratpoison. No mouse, no window title bars, in fact no overlapping windows (except modal popups), everything is maximized to full-screen, and you switch between them with keystrokes (which if you keep them <10 in number, you can address just by doing ctrl-T [0-9]). Remembering a number is easier than remembering a location, and at least you can see a simple numbered list when you ask the WM for it, not some jigsaw puzzle that you've to solve on the spot to find that window you minimized who knows on which other desktop. But I wouldn't recommend ratpoison to anyone except rabid hardcore CLI geeks like myself. Most people cringe when they see my "desktop" environment. "*That's* your OS?!" they would exclaim. It's just a wall of text. And then I would flip between a few windows, do some fg's and bg's, and they'd be completely lost. "What on earth did you just do? What's all those letters and symbols mean?" My wife sometimes asks me, "Do you really understand all this stuff?" when the screen is busy scrolling past during a large compile job. "How do you read all that stuff so quickly anyway?!" :-)
 Yeah. And worse yet, I've actually encountered GUI Linux apps that
 expect input from stdin. I'm not kidding. As they say, fact is
 stranger than fiction.

Eww. That's just...wow.

At least it's no worse than this one time, I had a browser plugin go *really* wrong, and it launches mplayer which somehow believes that it's being launched from a terminal instead of X11, and then it tries to read from the *browser's* stdin, causing the browser to get suspended by SIGTTOU, but when I try to fg the browser, it auto-backgrounds itself 'cos it wasn't designed to read from stdin. Or at least, I *think* that's what happens. Who knows. Something in there somewhere has gone completely wrong, so now *both* the browser *and* the plugin that launched mplayer are stuck in this limbo of trying to read stdin but it's not actually possible to type anything into it. :P
 The whole Unix philosophy is orthogonality, one tool to do one task
 well, no duplicated functionality for slightly-different use cases.
 The whole "sudo" vs "gtksudo/kdesudo" thing seems to be some sort
 of big ugly hack.

It's to prevent people from doing foolish things like logging in as root and doing everyday tasks as root, just because one or two commands *might* require root privileges. It's convenient, it's like Windows and DOS where you can do pretty much anything without this troublesome protection thing.

Oh, no, that's not what I meant. I understand the need for sudo, and I'm totally in favor of it. What bugs me is why we *also* have "gtksudo/kdesudo". Ie:

Ahhh, I see. Mea culpa. :) The reason is because that monstrosity known as X11 decided to trump the original Unix design, and implement a security protocol of its own. I won't get into the gory details here, but basically the usual su/sudo does give you root access, and the GUI app is actually running as root, but it needs to connect to X11 via a socket, and the X server has no way of knowing if the process it's talking to over the socket is running as root or not. So it asks for authentication tokens which root doesn't have, 'cos they're sitting in the original user's $HOME somewhere, but the GUI app doesn't know this, so it tries to look in root's $HOME and finds nothing. That's where gtksudo (or whatever it is they call that monstrosity) comes in: it not only gives you root access, but also sets up some environment vars in root's environment so that GUI apps launched from root will actually be able to find the original user's X11 authentication tokens (and possibly some KDE/GTK-specific stuff as well). Yeah I know. Wayyy over a newbie's head, for no good reason at all. T -- Give me some fresh salted fish, please.
Feb 21 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 07:45:36PM -0500, Nick Sabalausky wrote:
[...]
 Windows's cmd.exe always inserts a newline right before a command
 prompt. So you get the best of both worlds. Only issue is you end up
 with excess newlines. For example, you get:
 
 C:\>echo Hello > filea.txt
 
 C:\>echo Hello > fileb.txt
 
 C:\>

 Come to think of it, bash should be able to do the same thing if you add a 
 newline to the beginning of $PS1...
 
 Ha! It does work! Boy is that funny, it makes bash look like windows :) 
 That's just weird.

LOL... yeah that *is* weird.
 But, of course, it does mean a lot of extra blank lines. Which is ugly
 if you're doing a lot of no-output commands. But then, it's also much
 easier to read when there's a lot of heavy-output commands. It's a
 tradeoff :/

I was going to suggest writing a terminal wrapper to postprocess bash's output to compress unnecessary blank lines, but then I realized it won't work, 'cos bash does try to outsmart the outdated terminal concept by querying the kernel about what kind of stdout it's talking to. If it decides that the wrapper is a "dumb terminal", then you'll get a crippled shell with no meta keys, no history, no colors, no nothing except pure stream output. Which is a lot worse. And even if you manage to coax bash to work properly, this would probably also break most text-mode programs that try to do anything more than just write to stdout as a stream (like anything using ncurses). So the result would be totally unusable. :-( Oh well. T -- If creativity is stifled by rigid discipline, then it is not true creativity.
Feb 21 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 23, 2012 at 03:56:49AM +0100, Adam D. Ruppe wrote:
 I started the dshell just to waste a little time:
 
 http://arsdnet.net/dcode/dshell.d
 
         dmd dshell.d -L-lreadline -L-lncurses
 
 It doesn't do much here, but there's a few things I think
 are cool:
 
 1) D reflection rox. You can write D functions with simple
 arguments and it works basically. I want to detect bitfield
 enums to automatically do -flags too.

Nice!!! So you can write the same code for both the "shell library" and the actual shell itself.
 2) Your functions can return whatever, and it is wrapped in
 a runtime polymorphic range.

Cool, this is better than just plaintext stdin/stdout. :)
 If you just want strings, you can do ProgramDataByLine(input).
 
 If you want something fancier, you can use originalProgramData!Type
 to fetch out the original input range.

Nice.
 The syntax is so far just the basics... calling functions
 and pipes.

The echo command has a bug, it's not supposed to output 'echo' as part of its output. :)
 but hey its kinda cool already.

It's extremely cool. Definitely orders of magnitude better than writing the equivalent thing in C. Can you imagine the amount of code duplication & ugliness that you'd need in an equivalent C implementation? Without reflection, you'd either need hand-coded tables all over the place or insanely complex nested macros that nobody can understand. T -- GEEK = Gatherer of Extremely Enlightening Knowledge
Feb 23 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 23 February 2012 at 19:10:03 UTC, H. S. Teoh wrote:
 Nice!!! So you can write the same code for both the "shell 
 library" and the actual shell itself.

Yeah. This is similar to the technique I used in my web.d thing, though web.d's is a lot more complex. (It also handles sub objects, argument name and default values, and some more.) I just find it super useful.
 The echo command has a bug, it's not supposed to output 'echo' 
 as part of its output. :)

Yeah, I messed up argv. Here's an updated version: http://arsdnet.net/dcode/dshell.d added basic formatting to the data interface, lazy printing (try "cat" and type in stdin) and bug fixes. I just might put it up on the github over the weekend.
 It's extremely cool. Definitely orders of magnitude better than 
 writing the equivalent thing in C.

Hell, this kind of thing is easier in D than in a lot of dynamic languages! imo anyway. eval is sometimes nice but having the type information available to do a smart wrapper is very nice.
Feb 24 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Feb 26, 2012 at 05:10:35PM -0500, Nick Sabalausky wrote:
[...]
 I've just thought of (ie, gotten bit by) another thing that would be
 nice about having the commands do their own globbing:
 
 If the applications glob on their own insted of the shell, then for
 safety they can choose to restrict the number of file args they take
 to whatever makes sense for their own individual purpose.
 
 For example, suppose you want to delete everything inside a given
 subdirectory (but keep the directory itself). So then you (mis)type:
 
 $rm somedir/ * -rf
 
 Note the subtle space before the "*". I just did that by mistake
 earlier today, and the damage set me back a few hours (could have been
 much, much worse, though). I don't think there's much, if anything,
 that can realistically be done to protect against that right now. At
 least without getting really hacky.

If rm did its own globbing, it could warn the user before proceeding with a mass deletion involving *. (IIRC DOS's 'del' used to do this.) With the shell doing the expansion, there's no easy way to do this.
 But, if rm was expected to do its own globbing instead of the shell
 doing it, then rm could say: "Ok, it only makes sense for you to give
 me one file/path at a time. Want more? Run me multiple times or use a
 glob pattern (or hell, a regex pattern, or use a special explicit
 'accept multiple paths' mode, etc)." Then:
 
 $rm somedir/ * -rf
 ERROR: rm only takes one path at a time
 $rm somedir/* -rf  # ok
 $rm somedir/ -rf  # ok
 $rm * -rf  # ok
 
 With the shell doing the expansion, that sort of thing isn't even
 possible.

I guess you could have a flag for when you explicitly want to specify multiple filenames: $ rm abc.d def.d ERROR: rm only takes one path at a time $ rm -m abc.d def.d # ok $
 Works with other stuff too:
 
 $cp a b c
 ERROR: You gave me a source path and a destination path, but then you
 gave me *another* path! What the hell you expect *me* to do with it?

But sometimes you want to copy multiple files to a destination dir. But I suppose you can always use a glob or specify an option to say "yes I really want to copy multiple files into a target dir". T -- It is impossible to make anything foolproof because fools are so ingenious. -- Sammy
Feb 27 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 21 February 2012 15:06, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 Yeah, Unixland really works best with the "here's the source code,
 compile it yourself" model, rather than with the Windows "here's the
 binary executable" model. Gentoo's emerge is a step closer to making it
 more accessible to end-users (i.e. non-programmers who don't know what
 "compile" means), but still, compiling source code isn't always an
 option.

As a former Gentoo user, emerge is not user friendly (but neither is the OS in general), I get your point however. Arch Linux does well with the Arch Build System. pacman (the package manager) just installs the software the way the package tells it to, it has built-in support for remote repositories, but you can also just install local packages. This means that a system like the Arch User Repository works, since not everything in the official repos is update, and not everything is even /in/ the repos, I can normally go to the AUR, download a PKGBUILD archive, extract it, use makepkg to download+build it, then use pacman to install it. Not the simplest workflow in the world, but there are utilities like yaourt to make it easier (basically pacman for AUR). -- James Miller
Feb 20 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 21 February 2012 at 02:05:16 UTC, H. S. Teoh wrote:
 Same with Linux, I thought? Although I mainly just use vim for
 programming, so maybe I'm unaware of the full situation.

Yup.
 Terminal escape sequences?! You should be using libcurses or 
 libncurses.
 No wonder you had a bad experience. :)

They don't help that much, since they can't hide the underlying reality. Consider how you highlight some text in there. You'd have to do a change attributes, then a move, then a draw, then move back. ncurses has functions and macros to make it a little simpler, but not that much. (especially if your termcap is broken...) Mouse is a pain too. ncurses sometimes helps but what about gpm? Even old, fairly reliable programs have trouble with mouse. I do most my programming in vim, inside gnu screen, displayed in an xterm. Sometimes, it works great. Sometimes, though, if I click too far to the side.... it sends some bizarre sequence that vim interprets as a drag then input. The ugly escape sequences showed through to the end user (me)! Another bad one is when I open mysql on a remote server in my beloved rxvt, hit hte home key, and.... well, it is actually working for me today. But, I've many, many times had it say ^[~m or something like that. Ugh. Oh yeah, another one. Ever try to make an app in ncurses where you hold in a button? I believe it was shift+page up that I wanted, and its impossible because the terminal it is emulating didn't have a sequence for shift pressed, shift released, nor shift+page up. You could do that if you were talking to the hardware... but linux emulates some ancient pieces of trash, so you're left out. Oh oh, one more. Ever try to run a colored app in a different color terminal? vi with syntax highlighting fails easily. In vim, you can do :set bg=light. My vimrc has an environment variable I set (ELVISBG) for my various things. But... run it in screen. Start it in a white xterm. Detach and reattach to a black putty. The contrast is all wrong. There's no way for an app to query the colors in a unix terminal! Some ncurses apps just redraw the whole thing. Some use environment variables or something. But, there's no way without you telling it, and if things change, it is easy to get out of whack. Speaking of out of whack, ever resize a terminal connected to a remote session and see it not work? You're typing a long command, and it suddenly wraps back well before the edge and overwrites your old stuff. My god. Here's another one: have someone set a prompt with a wrong escape sequence. bash will mess up the length and will draw over your other stuff as you backspace. I've been using linux every day for about seven years now. I can go on all day! The windows one isn't perfect, not by any means, but it has a nice separation of control, input, and output. The Windows console api separates these things. You have an output buffer and an input event loop, with key and mouse events. You can set attributes on the cells (very much like the hardware again :) ) and get updates and query the system separately from the I/O channel. Much better design. If it did selecting by lines by itself and had nicer resizing, it'd be a real winner.
 But I agree with you though, that libc incompatibilities are 
 really really REALLY annoying.

Even worse is linux's binary incompatibilities. The dmd in the zip doesn't work out of the box on centos for instance... have to recompile it.
 That's why I'm liking D a lot, in spite of it still being under
 development and having nasty compiler/library bugs every now 
 and then.

D rox.
 That's more a bash limitation than anything, AFAIK.

Yes and no. bash (and the kernel) is good about it now, but it is an effect of the unix design of the shell doing the expansion. rm * could have sent argv == ["rm", "*"], and your app simply done foreach(a; glob(argv[1..$])) { delete(a); } or whatever. But, unix decided to do this in the shell. Which isn't all bad, it has some nice effects. But, run that in a folder with 20,000 items, and you send 20,000 strings in argv... Another side effect of this is rename *.html *.htm doesn't just work, since it is all expanded there. You have to make sure the wildcards are all at the tail of the command, so you have rename .htm .html *.htm instead. Not bad, and an easy rule to get used to, but kinda annoying at times.
 Besides, what *were* you
 trying to do with such a long command-line anyway? :-)

Once company I worked for had an old FreeBSD system that dumped tens of thousands of files in a few locations... which tended to fill up the disk. They had a cronjob to delete stuff every so often, but it grew big enough that the cron failed because there was too much to delete. And then the disk filled up and it was piles of fun. You'd be amazed at how many unix apps refuse to run if they can't write to /tmp!
 Most distros do distribute prebuilt binaries, but if your app 
 isn't part of the distribution, things get tough.

Aye, or if the version you need isn't in there. centos, I'm looking at you!
 But then again, I *did* also have to deal with having to repair 
 a remote Linux server whose dynamic linker broke

I've had that one too.... I had the luxury of being able to put in a cd though. Mount the drive and copy that stuff back to it.
Feb 20 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 23, 2012 at 06:02:30PM +1300, James Miller wrote:
[...]
 And I've been playing with trying to write my own terminal emulator. I
 actually kinda have one working, in C. I just need to wrap all the C
 code in functions and do all the interesting stuff in D.

 But I have plans for it, including some cool graphical stuff. I'm
 using clutter to render everything, so I can do all sorts of things
 with it, but to start with, I'd like to be able to display pictures
 inline, so you can do `cat my_pic.jpg` and rather throwing masses of
 garbage at you, it renders the picture, I might have to write my own
 cat to do so however...

Now *that* is an excellent idea! Perhaps there's a way of detecting JPEG or PNG output, say some kind of magic number detection ala /usr/bin/file. Buffer the first few bytes at output at the start of new lines, and if it looks like a JPEG file, buffer the rest of the output instead of displaying it immediately, and if after reading more input it does appear to be a valid JPEG file, then display it as an image. Otherwise flush the buffer and display it as text. To prevent problems with false positives causing output not to appear, you could use a timer: if the data type can't be determined within, say, 1/20 of a second, then skip the detection and display the output as text. Presumably if you do cat my_pic.jpg more than just the first few bytes will come out in the first 1/20 of a second, so it will pretty much reliably detect image data. Or you can do it the easy way by having a dedicated escape sequence that switches to image mode, and write a wrapper for cat that outputs this sequence when it detects image data in its output. The danger though is that you might get stuck in image mode if cat crashes before the image data is completely spooled, in that case it'll be like the ole DOS days when you got stuck in VGA mode when it has dropped back to the DOS prompt, and typing only produces line noise on the screen. :P T -- This is a tpyo.
Feb 22 2012
prev sibling parent James Miller <james aatch.net> writes:
On 23 February 2012 19:41, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 On Thu, Feb 23, 2012 at 06:02:30PM +1300, James Miller wrote:
 [...]
 And I've been playing with trying to write my own terminal emulator. I
 actually kinda have one working, in C. I just need to wrap all the C
 code in functions and do all the interesting stuff in D.

 But I have plans for it, including some cool graphical stuff. I'm
 using clutter to render everything, so I can do all sorts of things
 with it, but to start with, I'd like to be able to display pictures
 inline, so you can do `cat my_pic.jpg` and rather throwing masses of
 garbage at you, it renders the picture, I might have to write my own
 cat to do so however...

Now *that* is an excellent idea! Perhaps there's a way of detecting JPEG or PNG output, say some kind of magic number detection ala /usr/bin/file. Buffer the first few bytes at output at the start of new lines, and if it looks like a JPEG file, buffer the rest of the output instead of displaying it immediately, and if after reading more input it does appear to be a valid JPEG file, then display it as an image. =C2=A0Otherwise flush the buffer and display it a=

 text.

 To prevent problems with false positives causing output not to appear,
 you could use a timer: if the data type can't be determined within, say,
 1/20 of a second, then skip the detection and display the output as
 text. Presumably if you do cat my_pic.jpg more than just the first few
 bytes will come out in the first 1/20 of a second, so it will pretty
 much reliably detect image data.

 Or you can do it the easy way by having a dedicated escape sequence that
 switches to image mode, and write a wrapper for cat that outputs this
 sequence when it detects image data in its output. The danger though is
 that you might get stuck in image mode if cat crashes before the image
 data is completely spooled, in that case it'll be like the ole DOS days
 when you got stuck in VGA mode when it has dropped back to the DOS
 prompt, and typing only produces line noise on the screen. :P


 T

 --
 This is a tpyo.

I was thinking about both of those options and came to pretty much the same conclusions. What would be cool would be to add in new STD* file descriptors (ala STDIN, STDOUT, etc) that are dedicated to presentation (also means that you can output things to the terminal while running a pipe), however that would also require shell support (to set the correct FDs on the child process) and I'm not writing a terminal /and/ shell (yet). Otherwise, I think having the terminal take note of what is going on in the shell would solve the stuck mode problem, (which i encountered accidentally by putting my terminal into alt_charset mode) just have it notice if the current process is a shell or not and basically say "Shells can't be in image mode". It would probably require grabbing /etc/shells. The other advantage of using an escape sequence is that assuming that it can read fast enough, then it could easily be extended to all sorts of things, video for example. Displays a small video in the terminal, so you can check that the video is what you actually want, don't replace an actual movie player, that would be silly. you could also have things like syntax highlighting for supported files. As you can probably tell, I am less than enamored by the current terminal/shell line-up we have, I just think that there is so much more we could do with modern tech, and it doesn't need to even be incompatible with older systems!
Feb 23 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 21 February 2012 at 02:56:13 UTC, Juan Manuel Cabo 
wrote:
 many diskettes of slackware (no live cds at that time!, no easy

I love Slackware.
Feb 20 2012
prev sibling next sibling parent reply torhu <no spam.invalid> writes:
On 20.02.2012 22:36, Benjamin Thaut wrote:
 2) Will dmd support exporting/importing data symbols from dlls? I know
 there is a patch that does the data symbol address patching from the
 runtime but thats a feature that should be supported by the compiler
 directly in my eyes.

Importing data symbols works just fine both in DMD and GDC. At least it did a couple of years ago. Can't remember if I've tried exporting, but I wouldn't be surprised if it worked. You don't need to do anything special to get it working, just use declare the data as 'export extern extern (C)' in your D code. For D2 prefix that with '__gshared'. Not very elegent, but it does work.
Feb 20 2012
next sibling parent torhu <no spam.invalid> writes:
On 21.02.2012 04:08, torhu wrote:
 On 20.02.2012 22:36, Benjamin Thaut wrote:
  2) Will dmd support exporting/importing data symbols from dlls? I know
  there is a patch that does the data symbol address patching from the
  runtime but thats a feature that should be supported by the compiler
  directly in my eyes.

Importing data symbols works just fine both in DMD and GDC. At least it did a couple of years ago. Can't remember if I've tried exporting, but I wouldn't be surprised if it worked. You don't need to do anything special to get it working, just use declare the data as 'export extern extern (C)' in your D code. For D2 prefix that with '__gshared'. Not very elegent, but it does work.

I should mention that 'export' also works for importing. It does the job of both '__declspec(dllimport)' and '__declspec(dllexport)'.
Feb 20 2012
prev sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 21.02.2012 04:08, schrieb torhu:
 On 20.02.2012 22:36, Benjamin Thaut wrote:
 2) Will dmd support exporting/importing data symbols from dlls? I know
 there is a patch that does the data symbol address patching from the
 runtime but thats a feature that should be supported by the compiler
 directly in my eyes.

Importing data symbols works just fine both in DMD and GDC. At least it did a couple of years ago. Can't remember if I've tried exporting, but I wouldn't be surprised if it worked. You don't need to do anything special to get it working, just use declare the data as 'export extern extern (C)' in your D code. For D2 prefix that with '__gshared'. Not very elegent, but it does work.

I tried that but it does not work. For example compiler generatd data symbols like the module info or the vtable don't get exported even if the class is declared as "export" Also the tls storage does not work with threads across dll boundaries. And a lot of other stuff. I consider dll support working as soon as phobos is a shared dll. Kind Regards Benjamin Thaut
Feb 21 2012
parent torhu <no spam.invalid> writes:
On 21.02.2012 18:54, Benjamin Thaut wrote:
 Am 21.02.2012 04:08, schrieb torhu:
  On 20.02.2012 22:36, Benjamin Thaut wrote:
  2) Will dmd support exporting/importing data symbols from dlls? I know
  there is a patch that does the data symbol address patching from the
  runtime but thats a feature that should be supported by the compiler
  directly in my eyes.

Importing data symbols works just fine both in DMD and GDC. At least it did a couple of years ago. Can't remember if I've tried exporting, but I wouldn't be surprised if it worked. You don't need to do anything special to get it working, just use declare the data as 'export extern extern (C)' in your D code. For D2 prefix that with '__gshared'. Not very elegent, but it does work.

I tried that but it does not work. For example compiler generatd data symbols like the module info or the vtable don't get exported even if the class is declared as "export" Also the tls storage does not work with threads across dll boundaries. And a lot of other stuff. I consider dll support working as soon as phobos is a shared dll.

I see. I assumed you were talking about linking with DLLs written in C. I've never tried linking with a D DLL, except for maybe a simple test case.
Feb 21 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Feb 20, 2012 at 11:56:11PM -0300, Juan Manuel Cabo wrote:
 On 02/20/2012 11:06 PM, H. S. Teoh wrote:
 On Tue, Feb 21, 2012 at 02:00:20AM +0100, Adam D. Ruppe wrote:
 ...
 Yeah I remember that. I thought they've since fixed it, though.
 That's more a bash limitation than anything, AFAIK. Besides, what
 *were* you trying to do with such a long command-line anyway? :-)
 ...

I can think of one case where the command line argument limit is a problem: copying or moving files from a huge directory. In that case, to do it with bash, there is no other way around but to do things such as iterate over the alphabet to copy the files that start with 'a', then the ones with 'b'..

for x in *; mv $x dest/$x; done Easy. :) [...]
 But then again, I *did* also have to deal with having to repair a
 remote Linux server whose dynamic linker broke, causing basic
 commands like ls, cp, chmod, to be completely non-functional. In
 fact, *nothing* worked except that last remote login running bash.
 In the end I had to use bash's built-in echo command to recreate a
 statically-linked busybox binary via copy-n-pasting over the
 terminal, in order to get things back into working condition again.
 (Yeah. Definitely not for the faint of heart.)


 That is so COOL!! I remember f*cking up one of my first linux
 computers that way. If I had known, I wouldn't have to go back to
 reinstall the many diskettes of slackware (no live cds at that time!,
 no easy way to fix the fs).

That is only cool in retrospect. I remember sweating bullets at the time, thinking twice about every command I typed, lest I accidentally lose that last ssh session into the box. (New ssh connections don't work, for the same reasons.) Especially tense was when I used xclip to copy 10000 echo commands into the paste buffer and then pasted the result into the ssh terminal. You have no idea what a sigh of relief it was when it was finally done and the connection was still alive. :-P The slightest slip, like an accidental EOF at the wrong place in the paste, and it's bye-bye ssh connection, bye-bye remote server. T -- "I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly
Feb 20 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 21 February 2012 at 03:13:10 UTC, H. S. Teoh wrote:
 for x in *; mv $x dest/$x; done

 Easy. :)

And wrong! What if the filename has a space in it? You can say "$x", with quotes, to handle that. But, worse yet... a leading dash? Another downside with the shell expansion is the program can't tell if that is an expanded filename or a user option. In this case, the mv simply wouldn't work, but you can get some bizarre behavior out of that if you wanted to play with it. try this some day as a joke: $ mkdir evil-unix # toy directory $ cd evil-unix $ touch -- -l # our lol file $ touch cool # just to put a file in there $ ls -l cool $ ls * # the lol file is interpreted as an option! -rw-r--r-- 1 me users 0 2012-02-20 22:18 cool $ imagine the poor newb trying to understand that!
Feb 20 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 12:07:41AM -0300, Juan Manuel Cabo wrote:
 That is so COOL!! I remember f*cking up one of my first linux computers
 that way. If I had known, I wouldn't have to go back to reinstall the
 many diskettes of slackware (no live cds at that time!, no easy way
 to fix the fs).

What happened was (If I remember correctly) that I renamed the /lib directory. (PLEASE DON'T TRY THAT AT HOME!!)

Haha, ouch. That would suck, real bad. It could be worse. Some guy somehow messed up his packaging system so much that when he ran an upgrade command, the packager somehow decided that it had to uninstall EVERY package on the system (including essential stuff like /bin and /lib). Which it proceeded to do, until it deleted so much of the system that it broke itself and crashed. Leaving a system without /bin, /lib, or /usr. It was from this guy's website that I learned how to copy binary files using echo. :-)
 Again, this:
 
 In the end I had to use bash's built-in echo command to recreate a
 statically-linked busybox binary via copy-n-pasting over the
 terminal,


is so cool!!

I don't know if that's cool, or just plain crazy. You have no idea how hard it is to actually create an executable using echo commands. What with bash interpolating the input strings at various places multiple times, you have to double-escape, triple-escape, even quadruple-escape some of the hex sequences just to get it to work properly. For example, I had to represent a *single* binary 0 as \\\\0000, because I couldn't paste the commands directly at the prompt, since bash does something with the terminal after every line, so the input buffer would overflow and start truncating commands about 5-6 lines into the paste. So I had to use this hack: (IFS=$'\n';while read line;do echo "$line";done) > target.script to copy the pasted command into a script file, and then run that script afterwards. But the 'echo "$line"' introduced yet another level of interpolation, so what started out as \0 turned into \\\\0000. You could clean out your mouth several times over with that amount of toothpicks. :-P T -- Frank disagreement binds closer than feigned agreement.
Feb 20 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 04:00:17AM +0100, Adam D. Ruppe wrote:
 On Tuesday, 21 February 2012 at 02:05:16 UTC, H. S. Teoh wrote:
Same with Linux, I thought? Although I mainly just use vim for
programming, so maybe I'm unaware of the full situation.

Yup.
Terminal escape sequences?! You should be using libcurses or
libncurses.  No wonder you had a bad experience. :)

They don't help that much, since they can't hide the underlying reality.

 Even old, fairly reliable programs have trouble with mouse. I do most
 my programming in vim, inside gnu screen, displayed in an xterm.
 
 Sometimes, it works great. Sometimes, though, if I click too far to
 the side.... it sends some bizarre sequence that vim interprets as a
 drag then input.
 
 The ugly escape sequences showed through to the end user (me)!

I've always been of the opinion that ALL control sequences should be sent over a separate channel. Mixing controls with data (characters) is a Bad Idea(tm). But alas, if you were to implement such a terminal, pretty much *everything* would break, since everyone assumes the terminal is just a single stream of mixed controls + data. [...]
 Oh yeah, another one. Ever try to make an app in ncurses where you
 hold in a button? I believe it was shift+page up that I wanted, and
 its impossible because the terminal it is emulating didn't have a
 sequence for shift pressed, shift released, nor shift+page up.
 
 You could do that if you were talking to the hardware... but linux
 emulates some ancient pieces of trash, so you're left out.

Is that because you're trying to do this through gnu screen? I use screen all the time too, and I've discovered that it does really strange things with terminal settings. When I use ssh directly, these problems go away. Perhaps it's a bug in screen. [...]
 Oh oh, one more. Ever try to run a colored app in a different color
 terminal?

I'm not a fan of using colored terminals. It's trying to patch new functionality over an incompatible interface. You're bound to have problems.
 vi with syntax highlighting fails easily. In vim, you can do
 :set bg=light. My vimrc has an environment variable I set (ELVISBG)
 for my various things.
 
 But... run it in screen. Start it in a white xterm. Detach and
 reattach to a black putty.
 
 The contrast is all wrong.
 
 There's no way for an app to query the colors in a unix terminal!

Oh? I thought ncurses does.
 Some ncurses apps just redraw the whole thing. Some use environment
 variables or something.

But you're right that most ncurses apps just assume that once they start running, the colors will stay put. Assumption fails as soon as screen comes into the picture. Most *good* ncurses programs will repaint the screen on a keystroke, like ^L. But yeah, that's a workaround, not a solution. [...]
 Speaking of out of whack, ever resize a terminal connected to a remote
 session and see it not work? You're typing a long command, and it
 suddenly wraps back well before the edge and overwrites your old
 stuff.

I think you're seeing bugs in screen. I can resize my ssh terminals no problem, it manages to communicate that fact to the remote end, which sends a SIGWINCH to the app, which then resizes itself. This works in putty from Windows too. But once screen sits in the middle, all bets are off. [...]
 Here's another one: have someone set a prompt with a wrong escape
 sequence. bash will mess up the length and will draw over your other
 stuff as you backspace.

Heh, never seen that before. I usually just turn off all fancy settings after installing a new system, and just stick with a bare-bones prompt. [...]
 I've been using linux every day for about seven years now. I can go on
 all day!

Only seven years? ;-) I've been at it for several years longer. [...]
 The windows one isn't perfect, not by any means, but it has
 a nice separation of control, input, and output.
 
 The Windows console api separates these things. You have an output
 buffer and an input event loop, with key and mouse events. You can set
 attributes on the cells (very much like the hardware again :) ) and
 get updates and query the system separately from the I/O channel.

Oh? This must be new. The last time I actually programmed anything on Windows was... oh wait, it was on DOS. :P The creeping horror that was Windows 95 was one of the things that prompted me to switch to Linux for good. But I don't remember console I/O being so nice. They must've improved it since I last saw it.
 Much better design. If it did selecting by lines by itself and had
 nicer resizing, it'd be a real winner.

The fundamental problem with the Unix concept of terminal is that it wants to treat EVERYTHING as a stream of bytes. Which is a powerful abstraction, granted, but when it fails, like when escape sequences get out of sync, it fails in horrible ways. I've always argued that control and data needs a clean separation.
But I agree with you though, that libc incompatibilities are really
really REALLY annoying.

Even worse is linux's binary incompatibilities.

But that can't be helped when you have such proliferation of distros, OS versions, library versions, etc.. I almost never download binaries, only source. [...]
 Yes and no. bash (and the kernel) is good about it now,
 but it is an effect of the unix design of the shell
 doing the expansion.
 
 rm *
 
 could have sent argv == ["rm", "*"], and your app
 simply done foreach(a; glob(argv[1..$])) { delete(a); }
 or whatever.
 
 But, unix decided to do this in the shell. Which isn't
 all bad, it has some nice effects.

My favorite effect is this: mv filename.{oldext,newext} which only makes sense if the shell expands it. OTOH, I quite miss the good ole DOS days with Norton Commander, where you can type: rename *.oldext *.newext and it would do the right thing.
 But, run that in a folder with 20,000 items, and you send 20,000
 strings in argv...

I remember hitting an upper limit on that once, but I don't know if I remembered correctly.
 Another side effect of this is
 
 rename *.html *.htm
 
 doesn't just work, since it is all expanded there. You have
 to make sure the wildcards are all at the tail of the
 command, so you have
 
 rename .htm .html *.htm
 
 instead. Not bad, and an easy rule to get used to, but kinda annoying
 at times.

I find it *very* annoying. But still, with all its warts, I find myself much more productive at the commandline than at a GUI.
Besides, what *were* you trying to do with such a long command-line
anyway? :-)

Once company I worked for had an old FreeBSD system that dumped tens of thousands of files in a few locations... which tended to fill up the disk.

Ah. Ouch.
 They had a cronjob to delete stuff every so often, but it grew big
 enough that the cron failed because there was too much to delete.

LOL...
 And then the disk filled up and it was piles of fun. You'd be amazed
 at how many unix apps refuse to run if they can't write to /tmp!

Ugh. Don't remind me. At work I use ctags a lot so that I can use vim's tag function (super useful for navigating large source trees!). Then recently, some new code was introduced that produced hundreds of thousands of symbols... and ctags would soak up all RAM, thrash on I/O, near-freezing the computer, then die at the end when sort runs out of space in /tmp. It's both funny and sad at the same time.
Most distros do distribute prebuilt binaries, but if your app
isn't part of the distribution, things get tough.

Aye, or if the version you need isn't in there. centos, I'm looking at you!

That's why I love debian backports. :)
But then again, I *did* also have to deal with having to repair a
remote Linux server whose dynamic linker broke

I've had that one too.... I had the luxury of being able to put in a cd though. Mount the drive and copy that stuff back to it.

Provided 'mount' and 'cp' are statically linked, otherwise you're still screwed. Of course, if you could boot from CD, then you're OK. I didn't have the luxury: it was a remote server (hosted at a very remote location). T -- Don't throw out the baby with the bathwater. Use your hands...
Feb 20 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 21 February 2012 at 03:53:20 UTC, H. S. Teoh wrote:
 But alas, if you were to implement such a terminal,
 pretty much *everything* would break, since everyone assumes the
 terminal is just a single stream of mixed controls + data.

Yeah... I've been wanting to do it, but it'd mean redoing almost every app and that just isn't worth it.
 Is that because you're trying to do this through gnu screen?

The shift+ certain keys is a limitation of the terminal itself, not just screen. Now, screen sometimes does some weird things, but I've found it does a pretty good job on the whole. (really annoying is if you start up vim from a box with X. vim connects to X. Then detach it in screen and reattach in another window. vim dies with a BadWindow X error when you make a selection. Ugh.) Anyway screen works well with what it has. Even if it has bugs - terminal window titles never seem to be quite right with it for example - its so well worth it. screen is one of my favorite programs.
 Oh? I thought ncurses does.

The best I've seen is environment variables, which are easy to get out of sync.
 Most *good* ncurses programs will repaint the screen on a 
 keystroke,
 like ^L. But yeah, that's a workaround, not a solution.

Yea. And then you lose your custom color anyway, as the app repaints in its own way.
 Heh, never seen that before. I usually just turn off all fancy 
 settings
 after installing a new system, and just stick with a bare-bones 
 prompt.

I like slackware's default of \u \h:\w\$ Simple, informative, reliable. But, one of the sysadmins I worked with fell in love with colors. I still have access to one of his systems, let me pull this up... this system is slow! come on... Here we go: # echo $PS1 \033[0m\033[36mname\033[34mredacted\033[0m# Two different colors forming the system's name! And no useful info. This isn't a prompt. It's a logo. But, he loved it. And it is kinda cool, just blargh, especially when the escape sequences get broken up for whatever reason and the whole thing goes to hell. (Which is easy to happen - type a long line. bash offers a special sequence to let it know what you're escaping, but he didn't use it on this system so bash thinks the prompt is longer than it is, which breaks the line wrapping.)
 Only seven years? ;-) I've been at it for several years longer.

I'm relatively new but just as grizzled :-)
 Oh? This must be new.

I think Windows NT or maybe 2000 introduced it. I actually liked working with DOS though. Good old segment b800 where can just write your bytes and see them on screen. Fond memories here of video mode 13h too. That was easy programming, and good speed too, even on those old computers. When I finally switched to coding for these newfangled multitasking OSes, it took a long time to get used to not having my precious memory map.
 I've always argued that control
 and data needs a clean separation.

I agree entirely.
 I almost never download binaries, only source.

Me too, which is kinda sad when distributing software. I like sharing my apps with Windows users because I can say "grab this exe and have fun". With Linux users, there's always some list of third party stuff they need too. dmd, qt, whatever, but always something.
 My favorite effect is this:

 	mv filename.{oldext,newext}

 which only makes sense if the shell expands it.

Nice one!
 much more productive at the commandline than at a GUI.

command lines rock. Actually, I complain, but my system is a hacked up blackbox with rxvt and xterm on hotkeys, so I can summon and dismiss them with ease. (I put them on the menu key next to the right ctrl key. One press, rxvt comes. I can order it around, then ctrl+d to get rid of it. Easy come, easy go.) It works so well that I barely need anything else. What pains me most about using windows though? It isn't the command line.... it is that you can't turn off click to raise. You can turn on sloppy focus and it is decently usable. But, I've never found a way to make it so you can click a window without it going to the top. In fact, some Windows windows go to the top whenever they focus.... which kinda neuters sloppy focus too. Gah! I love that model. Stacking windows is just no fun if they always insist on going to the top.
 I didn't have the luxury: it was a remote server (hosted at a 
 very remote location).

That sucks.
Feb 20 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--00248c6a86e2e6cf4a04b975b86f
Content-Type: text/plain; charset=UTF-8

On 21 February 2012 01:00, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 On Mon, Feb 20, 2012 at 05:25:28PM -0500, Jonathan M Davis wrote:
 On Monday, February 20, 2012 22:36:49 Benjamin Thaut wrote:
 1) Is there a chance that dmd will support 64 bit on windows any
 time soon? What are the issues currently with 64 bit support on
 windows?  (optlink? backend?)

Neither support 64-bit. So, the changes required to the toolchain are _far_ greater for 64-bit Windows than the Posix OSes. It'll come eventually, but probably not for a while.

Does gdc support 64-bit? AFAIK it should, since it uses the gcc backend.

I use GDC in windows, and it's good. It's always up to date too, which is nice. --00248c6a86e2e6cf4a04b975b86f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 21 February 2012 01:00, H. S. Teoh <span dir= =3D"ltr">&lt;<a href=3D"mailto:hsteoh quickfur.ath.cx">hsteoh quickfur.ath.= cx</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Mon, Feb 20, 2012 at 05:25:28PM = -0500, Jonathan M Davis wrote:<br> &gt; On Monday, February 20, 2012 22:36:49 Benjamin Thaut wrote:<br> &gt; &gt; 1) Is there a chance that dmd will support 64 bit on windows any<= br> &gt; &gt; time soon? What are the issues currently with 64 bit support on<b= r> &gt; &gt; windows? =C2=A0(optlink? backend?)<br> &gt;<br> &gt; Neither support 64-bit. So, the changes required to the toolchain are<= br> &gt; _far_ greater for 64-bit Windows than the Posix OSes. It&#39;ll come<b= r> &gt; eventually, but probably not for a while.<br> </div></div>[...]<br> <br> Does gdc support 64-bit? AFAIK it should, since it uses the gcc backend.<br=
</blockquote><div><br></div><div>I use GDC in windows, and it&#39;s good. =

--00248c6a86e2e6cf4a04b975b86f--
Feb 21 2012
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 21.02.2012 10:06, schrieb Manu:
 On 21 February 2012 01:00, H. S. Teoh <hsteoh quickfur.ath.cx
 <mailto:hsteoh quickfur.ath.cx>> wrote:

     On Mon, Feb 20, 2012 at 05:25:28PM -0500, Jonathan M Davis wrote:
      > On Monday, February 20, 2012 22:36:49 Benjamin Thaut wrote:
      > > 1) Is there a chance that dmd will support 64 bit on windows any
      > > time soon? What are the issues currently with 64 bit support on
      > > windows?  (optlink? backend?)
      >
      > Neither support 64-bit. So, the changes required to the toolchain are
      > _far_ greater for 64-bit Windows than the Posix OSes. It'll come
      > eventually, but probably not for a while.
     [...]

     Does gdc support 64-bit? AFAIK it should, since it uses the gcc backend.


 I use GDC in windows, and it's good. It's always up to date too, which
 is nice.

Do you build GDC yourself or are you using a precompiled version? If you build it yourself which gcc source do you use? Kind Regards Benjamin Thaut
Feb 21 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-20 22:36, Benjamin Thaut wrote:

 3) Am I mistaken or are most of the people here using dmd under linux?
 General bugs or linux only bugs tend to get fixed a lot faster then
 windows only bugs.

Mac OS X here. -- /Jacob Carlborg
Feb 21 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Unless things have changed dramatically in the past few years, SUA is =
barely usable though.  The shells don't behave the same way as their =
*nix equivalents and the API coverage is spotty at best.  If you really =
want to go the Posix on Windows route I'd suggest either downloading =
GnuWin32 (for tools that can be run from the Windows command-line) or =
Cygwin (for a full programming environment).  Having once made an =
attempt at porting a large Solaris app to Interix (aka SUA), I feel =
pretty comfortable in saying that native Posix support under Windows is =
there more to be listed as a feature for government contracts or =
whatever than because it's something anyone would actually want to use.

For SSH support, I'd suggest getting a client/server app from somewhere =
like Vandyke Systems, then maybe grabbing Windows PowerShell from =
Microsoft.  It will be a lot more effective than trying anything =
built-in.

On Feb 21, 2012, at 12:08 AM, Paulo Pinto wrote:

 They did, but Microsoft way as usual.
=20
 SSH in Windows, means making use of Powershell remote access. SSH is =

 for UNIX compatibility and it works better if SUA (UNIX personality) =

=20
 --
 Paulo
=20
 "Andrei Alexandrescu"  wrote in message =

=20
 On 2/20/12 6:41 PM, Adam D. Ruppe wrote:
 On Tuesday, 21 February 2012 at 00:38:46 UTC, Andrei Alexandrescu =


 ssh into Windows and... well last time I did it it was like "welcome
 to Hell".

Oh, certainly!

Rats. I was hoping the boys in Redmond have improved the situ since. =20 Andrei=20

Feb 21 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 01:48:35PM -0500, Nick Sabalausky wrote:
[...]
 Another issue with it is that to make a binary work on both an older
 and newer Linux, you have to actually compile it *on* an older Linux.
 I've heard that, in theory, you can use a newer Linux to create
 binaries that work on older systems, but in practice, nobody actually
 knows how.

Oh, there are ways to do that, sure. You can always make a chroot and install an old version in it, then do your compilation there. Disadvantage: it's a major pain to move files back and forth and get the compiler to be installed properly in the chroot. You can't (easily) just build everything in your source tree, since the build has to be run under the chroot. Or you could build a cross-compiler and fiddle with gcc path settings to coax it to link to old libraries instead. Or if you're brave, build a multi-target compiler. But you still have to deal with coaxing the linker to find older libs instead of new ones. This is arcane black magic that will explode in your face if you don't know what you're doing, unfortunately. [...]
 Eeeww. I had no idea the shell did the expansion. That's just awful.

Awful in some ways, powerful in others. Shell expansion allows you to do stuff like: mv myfilena{e,}me.ext to correct a misspelt filename, for example. But shell expansion also forces you to write \\\\0000 instead of \00, so I can't say with a straight face that it's definitely a good thing. Me, I personally wished that instead of shoving all that functionality into the shell, they would've just provided a library that did these standard things so that programs could use them as needed. IIRC, glob() was originally only implemented in the shell; it was only later that it actually became a library usable by other programs. [...]
 Maybe I don't understand the way the package/dep managers work well
 enough, but it always seemed bad to me that you can't do:
 
 $sudo apt-get install [url to an apt-compatible package]

If you filed a bug on bugs.debian.org and ask nicely, somebody may implement that for you. :)
 Or whatever the yum equivalent would be.
 
 Erm, at least, I don't *think* you can...Maybe I'm wrong? In any case,
 having to mess with the sources list sucks.

For isolated packages I find online, I usually just do this: wget http://server.com/path/to/package.deb dpkg -i package.deb Mission accomplished. Well, provided there are no nasty dependencies. :) If there are, there's currently no choice but to edit /etc/apt/sources.list.
 Linux is definitely groing on me more and more, but you're right, it
 does have it's quirks.

The thing is, the *concepts* behind the OS are rock solid, but the implementation suffers from decades of historical accidents that led to a working but sometimes quite counterintuitive system. For example, what on earth does "grep" mean anyway?! (Yes I know what it means. I'm just saying, it's a totally stupid name for that utility.) And "cat"? It that supposed to meow? And what on earth does "etc" stand for anyway, and what has it gotta do with configuration files?! Or my favorite syscall, creat(). Apparently in the old days there was only one E on the keyboard. Oh wait... :P There are also little flaws inherited from decades-old conventions that nobody dares break, lest existing code fail in new and mysterious ways. Or not-so-mysterious ways, like if you redesign the terminal protocol to be more in line with modern computing. But whine as I may, I still love my Linux systems, both at home and at work. I know how to sing to their tune and make them dance. Whereas Windows just stares at me with a blue face. T -- Only boring people get bored. -- JM
Feb 21 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.811.1329854653.20196.digitalmars-d puremagic.com...
 On Tue, Feb 21, 2012 at 01:48:35PM -0500, Nick Sabalausky wrote:
 [...]
 Another issue with it is that to make a binary work on both an older
 and newer Linux, you have to actually compile it *on* an older Linux.
 I've heard that, in theory, you can use a newer Linux to create
 binaries that work on older systems, but in practice, nobody actually
 knows how.

Oh, there are ways to do that, sure. [...] This is arcane black magic that will explode in your face if you don't know what you're doing, unfortunately.

Exactly.
 [...]
 Eeeww. I had no idea the shell did the expansion. That's just awful.

Awful in some ways, powerful in others. Shell expansion allows you to do stuff like:

Actually, I specifically meant glob expansion. I do think it's good that, for example, env var expansion occurs in the shell - I can't imagine that working well otherwise. Quoted args should also be handled by the shell: $touch 'My Modern Filename.txt' Speaking of cmdline args and argv, I've written this trivial 'showargs' utility which I find indispensable for examining/experimenting/debugging cmd line params: ---------------------------------------------- import std.stdio; void main(string[] args) { writefln("args.length: %s", args.length); foreach(i, arg; args) writefln("args[%s]: '%s'", i, arg); } ---------------------------------------------- $ dmd showargs.d $ ./showargs ' hi world ' hi world '' x ' ' args.length: 7 args[0]: './showargs' args[1]: ' hi world ' args[2]: 'hi' args[3]: 'world' args[4]: '' args[5]: 'x' args[6]: ' ' ---------------------------------------------- Does something like that already exist in Unix that I've overlooked?
 mv myfilena{e,}me.ext

 to correct a misspelt filename, for example.

That's not a bad trick, I'll have to remember it.
 Me, I personally wished that instead of shoving all that functionality
 into the shell, they would've just provided a library that did these
 standard things so that programs could use them as needed.

For globs, at the very least, I definitely agree.
 IIRC, glob() was originally only implemented in the shell; it was only
 later that it actually became a library usable by other programs.

I see, that would certainly explain it then.
 [...]
 Maybe I don't understand the way the package/dep managers work well
 enough, but it always seemed bad to me that you can't do:

 $sudo apt-get install [url to an apt-compatible package]

If you filed a bug on bugs.debian.org and ask nicely, somebody may implement that for you. :)

Yea, probably worth a shot... Actually, I wonder if aptitude might already do it? (Hmm, doesn't look like it. At least if it does, the man page doesn't seem to mention it.)
 Linux is definitely groing on me more and more, but you're right, it
 does have it's quirks.

The thing is, the *concepts* behind the OS are rock solid,

Oh yea, no arguments here.
 but the
 implementation suffers from decades of historical accidents that led to
 a working but sometimes quite counterintuitive system. For example, what
 on earth does "grep" mean anyway?! (Yes I know what it means. I'm just
 saying, it's a totally stupid name for that utility.) And "cat"? It that
 supposed to meow? And what on earth does "etc" stand for anyway, and
 what has it gotta do with configuration files?!

Agree again ;)
 Or my favorite syscall, creat(). Apparently in the old days there was
 only one E on the keyboard. Oh wait... :P

 There are also little flaws inherited from decades-old conventions that
 nobody dares break, lest existing code fail in new and mysterious ways.
 Or not-so-mysterious ways, like if you redesign the terminal protocol to
 be more in line with modern computing.

I think the way to do that would be to make it a completely alternative protocol that software has to specifically choose to support. Sure, it's be next-to-useless at first, but eventually support could build up to critical mass and finally tip the scale. Similar to the approach of Wayland. (On the other hand, IPv6 still isn't the de facto standard...)
 But whine as I may, I still love my Linux systems, both at home and at
 work. I know how to sing to their tune and make them dance. Whereas
 Windows just stares at me with a blue face.

For me, Windows is an old friend (or at least XP anyway) and I know how to deal with it. But over the last decade my respect for Linux has slowly grown and grown. I thought Linux was in a pretty bad state around 2001 and temporarily wrote it off. But at this point, I think that if Linux had these four things: 1. A nice GUI file manager I really liked (including TortoiseGit-style functionality and Windows's quick image viewer). 2. A port of Programmer's Notepad 2 (or if I found something very, very similar. I'm not an emacs, vi, or eclipse kinda guy. Normally I use kate or gedit on Linux, but they're both still painful compared to PN2). 3. A good GUI SMART monitor comparable to Hard Disk Sentinel (not just something with an utterly useless manually-polled interface). 4. A music library manager that worked like iTunes/WinAmp/Foobar2000 (but hopefully wasn't shitty like iTunes and WinAmp and didn't have Foobar's limitations). There's a few other things that would be really, really nice to have too (like a video player up-to-par with Media Player Classic HC, and DVD Decryptor, DVD Shrink, and uTorrent...I *do* have totally legit uses for all those!). But those four main things listed above: I think those would probably be enough for me to feel comfortable making Linux my primary OS and leave Windows as my secondary. In fact, I really am itching for that to happen. In the meantime, I've been considering giving MSYS/MinGW another chance. I've had bad experiences with it before, but I've seen hints that things may have improved since then.
Feb 21 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 24, 2012 at 12:38:52AM +1300, James Miller wrote:
 On 23 February 2012 19:41, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 Perhaps there's a way of detecting JPEG or PNG output, say some kind
 of magic number detection ala /usr/bin/file. Buffer the first few
 bytes at output at the start of new lines, and if it looks like a
 JPEG file, buffer the rest of the output instead of displaying it
 immediately, and if after reading more input it does appear to be a
 valid JPEG file, then display it as an image. Otherwise flush the
 buffer and display it as text.


 Or you can do it the easy way by having a dedicated escape sequence
 that switches to image mode, and write a wrapper for cat that
 outputs this sequence when it detects image data in its output.


 I was thinking about both of those options and came to pretty much the
 same conclusions. What would be cool would be to add in new STD* file
 descriptors (ala STDIN, STDOUT, etc) that are dedicated to
 presentation (also means that you can output things to the terminal
 while running a pipe), however that would also require shell support
 (to set the correct FDs on the child process) and I'm not writing a
 terminal /and/ shell (yet).

Well, currently you *can* output to terminal in a pipe by writing to stderr, which usually points to the terminal even if stdout has been redirected. Of course, the user can redirect stderr too, but in that case he doesn't *want* any terminal output, so there's no point fighting it.
 Otherwise, I think having the terminal take note of what is going on
 in the shell would solve the stuck mode problem, (which i encountered
 accidentally by putting my terminal into alt_charset mode) just have
 it notice if the current process is a shell or not and basically say
 "Shells can't be in image mode". It would probably require grabbing
 /etc/shells.

The problem is that the terminal doesn't know who's sending output to it. It's just reading one end of a pipe, and anything could be at the other end, and there could be an arbitrary number of stuff in between. I'm not sure I know any easy and reliable way to solve this.
 The other advantage of using an escape sequence is that assuming that
 it can read fast enough, then it could easily be extended to all sorts
 of things, video for example. Displays a small video in the terminal,
 so you can check that the video is what you actually want, don't
 replace an actual movie player, that would be silly. you could also
 have things like syntax highlighting for supported files.

Actually, if the terminal supported video output, you could actually have the movie player play inside the terminal. :P Or am I just being silly?
 As you can probably tell, I am less than enamored by the current
 terminal/shell line-up we have, I just think that there is so much
 more we could do with modern tech, and it doesn't need to even be
 incompatible with older systems!

True. Taking the idea of an in-terminal video player further, what about a general escape sequence for "application-specific output"? This can then be used along with file type (data type) detection to multiplex between different apps, like image display, movie player, sound player, etc.. The apps will have access to a given region on the terminal screen (perhaps passed as a subwindow on the underlying windowing system), and can do whatever they want with it. This also means you don't need ncurses anymore. The app can get direct access to the terminal as a graphical drawable, and can do much more than displaying a bunch of characters in a grid. T -- It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford
Feb 23 2012
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 23 February 2012 at 21:17:35 UTC, H. S. Teoh wrote:
 Taking the idea of an in-terminal video player further, what 
 about a general escape sequence for "application-specific 
 output"?

<html>..... seriously, once you take the in-terminal stuff too far, you have a beast of a program that does everything; you end up with something like a web browser or nested X server, and you've lose the original beauty of the terminal. This is the path I started on, and ended up with what I called the D Windowing System - which is still on my todo list, but has been for a long time and will surely be for a long time more. But, I started with a terminal that can optionally output images. Then wanted improved character display and figured if it does images, it can be a bitmap drawable. Then wanted multiple channels... and at this point, you have a poor man's X. Realizing this, I went full into it and shifted gears to a higher level X kind of thing, where you make an app based on widgets on a grid, which would work in text mode or graphical mode. But, I didn't get too far before work took over my time. But, on a terminal, I just don't think images are a fit there. Might as well just make something like a gui image viewer app and keep a more traditional terminal. Though, I'd prefer to be more like vga text mode than VT100 in terms of capabilities.
Feb 23 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 11:50:24AM -0500, Nick Sabalausky wrote:
[...]
 I literally grew up on command-lines[1]. But despite that, I still
 much prefer GUIs for anything a GUI reasonably works for: Like file
 browsers, DB admin, manual DB queries, debuggers, Tortoise*, etc.
 (although for web server configuration I've come to vastly prefer
 config files - MUCH easier to remotely manage, plus the settings for
 files/paths are necessarily tied to the file/path *name*, not the
 physical file, so you don't kave to keep messing with them every time
 something's moved/renamed/deleted/recreated)

OK, this isn't exactly GUI, but have you tried mc? I remember in the good ole DOS days, Norton Commander (of which mc is a clone) was one of the best things around. It made DOS usable. In fact, even pleasant.
 When I'm on Linux, I've come to do most things on the command line
 just because 1. Many things still can only be done on the cmd line,
 and 2. Linux file managers suck about as much as the Windows command
 line. I'm proficient with bash, and I do love it as far as command
 lines go (And damn near anything can be scripted, which is fantastic),
 but I hate using it for file manipulation - just seems really clumsy
 compared to a *good* GUI file manager (which I've yet to find on
 Linux). Although the autocomplete *is* a huge help.

Yeah, you should check out mc. Though I haven't used it for at least a decade, so I can't vouch for whether it's still usable. I've yet to find a better file manager than the original NC, though.
 Although that said, even the Windows file manager has been plummeting 
 downhill ever since Vista. I don't know wtf MS has been thinking.

I hate the windows file manager with a passion. It's so difficult to make it display things properly, there's no way (not easily anyway) to specify a glob filter in a huge directory, change sorting criteria with a keystoke, etc.. I find `ls | grep` much more palatable than that painful 1-pixel wide horizontal scrollbar that leaps several pages per pixel when you're trying to find something in a truly huge directory, I mean folder.
 Keyboard/mouse switching comes pretty naturally to me. Part of it's
 probably years of practice, and the other part is that I use
 trackballs which tend to mostly stay put.

I used to do a lot of keyboard/mouse switching too. Until I switched to ratpoison, a window manager that doesn't require the mouse. Since then I've found that my speed almost doubled. Keyboard/mouse switching is much better when it's a laptop with that "nipple" thing in the middle of the keyboard. In fact, that's the only case of mouse-switching that is comparable in speed to a keyboard-only interface. Unless, of course, you're trying to manipulate graphical stuff like draw freehand curves, in which case you'll want to be on the mouse 99% of the time anyway. For discrete tasks like typing or navigating menus, keyboard shortcuts are unbeatable.
 [1] First AppleSoft BASIC and occasionally the built-in memory-editor
 and AppleSoft Logo. Later, MS-DOS 6-ish and occasionally gwbasic
 (normally used QBASIC instead, though)

Ooooh! Another Apple II veteran! Ah, the good ole Apple II. Believe it or not, my dad actually still has a couple o' 30-year-old Apple II's that he actually *still uses*. He wrote a little personal accounting app in Dbase, and has been using it for the last 3 decades. Never felt the need to upgrade. Of course, now he also has a modern-day laptop and modern PCs in the office. But that old faithful Apple II is still chugging away... T -- Береги платье снову, а здоровье смолоду.
Feb 21 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.812.1329855805.20196.digitalmars-d puremagic.com...
 On Tue, Feb 21, 2012 at 11:50:24AM -0500, Nick Sabalausky wrote:
 [...]
 I literally grew up on command-lines[1]. But despite that, I still
 much prefer GUIs for anything a GUI reasonably works for: Like file
 browsers, DB admin, manual DB queries, debuggers, Tortoise*, etc.
 (although for web server configuration I've come to vastly prefer
 config files - MUCH easier to remotely manage, plus the settings for
 files/paths are necessarily tied to the file/path *name*, not the
 physical file, so you don't kave to keep messing with them every time
 something's moved/renamed/deleted/recreated)

OK, this isn't exactly GUI, but have you tried mc?

Umm, I don't *think* so, unless you count mcedit. For a breif while I used mcedit as my preferred remote-file text editor, since it was text-mode (so it worked through ssh) and was slightly better than nano/pico. But I haven't had much need for it ever since I realized I could do this: $sshfs user domain:/ mount-point $kate mount-point/remote-path & I'll take a look though.
 I remember in the good ole DOS days, Norton Commander (of which mc is a
 clone) was one of the best things around. It made DOS usable. In fact,
 even pleasant.

Hmm, if that's like Total Commander on Windows, then I don't think I would like it. I do *love* Total Commander's multi-file renaming, but that feature is really the only reason I keep it around. Heh, as bad as this might sound, I think what I basically want is more or less Windows Explorer on linux ;) (Including the customizations I've installed, like "DOS Prompt Here" and Tortoise*) And yea, Explorer works under wine, but it's kinda like running a GTK app in Windows - but worse since Windows GTK apps at least *know* what OS they're really running on.
 Although that said, even the Windows file manager has been plummeting
 downhill ever since Vista. I don't know wtf MS has been thinking.

I hate the windows file manager with a passion. It's so difficult to make it display things properly, there's no way (not easily anyway) to specify a glob filter in a huge directory, change sorting criteria with a keystoke, etc.. I find `ls | grep` much more palatable than that painful 1-pixel wide horizontal scrollbar that leaps several pages per pixel when you're trying to find something in a truly huge directory, I mean folder.

Yea. While Windows Explorer is my favorite file manager, even I'll readily admit it's not perfect: - It keeps locking files/dirs for no apperent reason and keeps them locked. - Sometimes it has a hard time in dirs with lots of files, especially in thumbnail mode. - Search is slow. - It doesn't have a built-in "Extension" column, just that useless "Type" column. There's a third-party extension to add an "ext" column, but it's confused by zip files and it conflicts with the columns added by Tortoise*, so in many folders, instead of my "ext" column, it often gives me this useless "Product Version" column instead. But implementation issues aside (which I've more or less gotten used to), I like the basic UI itself a lot. In XP anyway. They really fucked up its UI in Vista and 7.
 Keyboard/mouse switching comes pretty naturally to me. Part of it's
 probably years of practice, and the other part is that I use
 trackballs which tend to mostly stay put.

I used to do a lot of keyboard/mouse switching too. Until I switched to ratpoison, a window manager that doesn't require the mouse. Since then I've found that my speed almost doubled. Keyboard/mouse switching is much better when it's a laptop with that "nipple" thing in the middle of the keyboard. In fact, that's the only case of mouse-switching that is comparable in speed to a keyboard-only interface. Unless, of course, you're trying to manipulate graphical stuff like draw freehand curves, in which case you'll want to be on the mouse 99% of the time anyway. For discrete tasks like typing or navigating menus, keyboard shortcuts are unbeatable.

I like to call it the clit mouse. It beats the shit out of trackpads (I hate those things with a passion), but I still find them a pain compared to mice and my trusty Logitech trackball. So I'm the opposite of you there: I actually find it much *easier* to switch between keyboard and trackball than keyboard and "clit mouse" despite the increased distance. Maybe I'm just weird.
 [1] First AppleSoft BASIC and occasionally the built-in memory-editor
 and AppleSoft Logo. Later, MS-DOS 6-ish and occasionally gwbasic
 (normally used QBASIC instead, though)

Ooooh! Another Apple II veteran! Ah, the good ole Apple II. Believe it or not, my dad actually still has a couple o' 30-year-old Apple II's that he actually *still uses*. He wrote a little personal accounting app in Dbase, and has been using it for the last 3 decades. Never felt the need to upgrade. Of course, now he also has a modern-day laptop and modern PCs in the office. But that old faithful Apple II is still chugging away...

Wow. Nice. I have an Apple IIc in a pile on the floor here to my right. Haven't had time to play with it in forever though. It's the same model I grep up on (IIc), but not the same physical machine. *God* I wish I hadn't sold my floppies along with my original system. I really wish I still had all that old data of mine. Probably all gone forever now: Overwritten, decayed, or in a landfill. :( I'm actually a huge Apple hater ever since I got fed up with my 10.2 eMac and the whole "Return of Jobs" world and product lines in general. But I *always* consider Woz's Apple II line to be the big, giant, glaring exception in Apple's portfolio.
Feb 21 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 21 February 2012 at 22:26:34 UTC, Nick Sabalausky 
wrote:
 On other thing I meant to mention: It's kinda annoying on Linux 
 how if you launch a gui app at the command line, it will
 automatically be a blocking foreground process unless
 you remember to add "&" at the end. Which I always forget.

You can also hit ctrl+z in that terminal to pause the gui app, then hit "bg" in there to move it to the background. Tho it still spams the text iirc. I kinda like how linux apps keep it though. It's just so easy to throw in a printf() from time to time to tell something to me without doing a popup window or something.
Feb 21 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
Nick replied to something about globbing

into someone who doesn't play ball. *cough* every single digital mars utility *cough*. I think Windows and unix both get it wrong, but unix gets it less wrong (as it could theoretically be annoying, but in practice I just escape it and move on, but working around a non-globbing program is just annoying). Wot I think should happen: the runtime (say libc) should handle globbing of arguments, and it should be enabled by default. So if someone wants an app that handles wildcards specially, they can do that, but for most apps it'll just work™. I don't think this really meshes with the traditional main signature of just passing the strings as arguments. Perhaps just a non_globbed_args function or something. Buuuut things are pretty much set in stone at this point.
Feb 21 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 06:01:37PM -0500, Nick Sabalausky wrote:
[...]
 Hmm, if that's like Total Commander on Windows, then I don't think I
 would like it. I do *love* Total Commander's multi-file renaming, but
 that feature is really the only reason I keep it around.
 
 Heh, as bad as this might sound, I think what I basically want is more
 or less Windows Explorer on linux ;)  (Including the customizations
 I've installed, like "DOS Prompt Here" and Tortoise*) And yea,
 Explorer works under wine, but it's kinda like running a GTK app in
 Windows - but worse since Windows GTK apps at least *know* what OS
 they're really running on.

Maybe if you write one in D... ;-) Perhaps *that's* the killer D app that we've been waiting for, that will take the world by a storm. :P [...]
 Keyboard/mouse switching is much better when it's a laptop with that
 "nipple" thing in the middle of the keyboard. In fact, that's the only


 I like to call it the clit mouse. It beats the shit out of trackpads (I hate 
 those things with a passion), but I still find them a pain compared to mice 
 and my trusty Logitech trackball. So I'm the opposite of you there: I 
 actually find it much *easier* to switch between keyboard and trackball than 
 keyboard and "clit mouse" despite the increased distance. Maybe I'm just 
 weird.

Are you trying to out-weird me? ;-) [...]
 Ooooh! Another Apple II veteran! Ah, the good ole Apple II. Believe
 it or not, my dad actually still has a couple o' 30-year-old Apple
 II's that he actually *still uses*. He wrote a little personal
 accounting app in Dbase, and has been using it for the last 3
 decades. Never felt the need to upgrade. Of course, now he also has
 a modern-day laptop and modern PCs in the office. But that old
 faithful Apple II is still chugging away...

Wow. Nice. I have an Apple IIc in a pile on the floor here to my right. Haven't had time to play with it in forever though. It's the same model I grep up on (IIc), but not the same physical machine. *God* I wish I hadn't sold my floppies along with my original system.

Hmm. I'm really dating myself now, but I grew up with the *original* Apple II, not even the IIc. I think I did get a IIc later on, but I got caught up with IBM PCs around the time Macs started coming out. Haven't been back to Apple since.
 I really wish I still had all that old data of mine. Probably all gone
 forever now: Overwritten, decayed, or in a landfill. :(

Well, even if you did have those old disks... they probably would've demagnetized by now. Perhaps. OTOH, ftp.apple.asimov (together with an Apple II emulator) is a wonderful resource for those moments of nostalgia, when you're just feeling that urge to go boot up with a single beep and see that beautiful "]█" prompt staring at you, just like it used to decades ago. And then you 'call -151' and geek out on coding some assembly routines by typing in opcodes, etc..
 I'm actually a huge Apple hater ever since I got fed up with my 10.2
 eMac and the whole "Return of Jobs" world and product lines in
 general. But I *always* consider Woz's Apple II line to be the big,
 giant, glaring exception in Apple's portfolio.

Ah, good ole Wozniak. Wasn't he the one who practically single-handedly coded up the entire Apple II ROM? Or am I just mixing up urban legend with reality? :) T -- Just because you can, doesn't mean you should.
Feb 21 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.830.1329870386.20196.digitalmars-d puremagic.com...
 On Tue, Feb 21, 2012 at 06:01:37PM -0500, Nick Sabalausky wrote:
 [...]
 Hmm, if that's like Total Commander on Windows, then I don't think I
 would like it. I do *love* Total Commander's multi-file renaming, but
 that feature is really the only reason I keep it around.

 Heh, as bad as this might sound, I think what I basically want is more
 or less Windows Explorer on linux ;)  (Including the customizations
 I've installed, like "DOS Prompt Here" and Tortoise*) And yea,
 Explorer works under wine, but it's kinda like running a GTK app in
 Windows - but worse since Windows GTK apps at least *know* what OS
 they're really running on.

Maybe if you write one in D... ;-) Perhaps *that's* the killer D app that we've been waiting for, that will take the world by a storm. :P

I've seriously been wanting to, but it's one of many things I haven't been able to get around to yet. I suspect, though, it might not end up so popular. Linux people like the command line. Although it might help further popularize Linux among WinXP fans... But it's looking like Vlad's D forums might be on their way to being D's killer app anyway ;)
 [...]
 Keyboard/mouse switching is much better when it's a laptop with that
 "nipple" thing in the middle of the keyboard. In fact, that's the only


 I like to call it the clit mouse. It beats the shit out of trackpads (I 
 hate
 those things with a passion), but I still find them a pain compared to 
 mice
 and my trusty Logitech trackball. So I'm the opposite of you there: I
 actually find it much *easier* to switch between keyboard and trackball 
 than
 keyboard and "clit mouse" despite the increased distance. Maybe I'm just
 weird.

Are you trying to out-weird me? ;-)

Heh heh. That's puts me in mind of one of my favorite songs: "[...] The so-called weirdos in this country Stand as completely freaked out by the normal man As the normal man is completely freaked out By the weird masses reaction to him Which came first, you may ask Chicken or egg, you may ask Well, the chicken of course It's time to break this weird-ass chain The weird masses don't want to be normalized Weirdos want to be abnormal The freaks can't be formally normalized Nor can we normally formalized What we want is complete weirdification Basically, we don't want weirdness from the normal man We don't want to be freaked out by the normal man We want to out freak the normal man [...] Because you are defending our weird women From the freaky-ass thoughts of the bug-eyed Bow-legged normal man" - Butthole Surfers: Weird Revolution Heh :)
 OTOH, ftp.apple.asimov (together with an Apple II emulator) is a
 wonderful resource for those moments of nostalgia, when you're just
 feeling that urge to go boot up with a single beep and see that
 beautiful "]?" prompt staring at you, just like it used to decades ago.
 And then you 'call -151' and geek out on coding some assembly routines
 by typing in opcodes, etc..

Yea, I had an Apple II emulator (fantastic!) and some disk images, but I think I may have lost them all last time I had a HDD die. Gotta recollect that stuff...
 I'm actually a huge Apple hater ever since I got fed up with my 10.2
 eMac and the whole "Return of Jobs" world and product lines in
 general. But I *always* consider Woz's Apple II line to be the big,
 giant, glaring exception in Apple's portfolio.

Ah, good ole Wozniak. Wasn't he the one who practically single-handedly coded up the entire Apple II ROM? Or am I just mixing up urban legend with reality? :)

My understanding is that he designed the whole damn machine, period. And I have a tendency to believe it, because those older systems really *are* simple enough that it's totally possible for one person to understand every byte, every clock cycle, every chip and every wire. Hell, that's a big part of what makes those machines such a dream to work with anyway. And also what made them cheap enough for average consumers - *especially* the Atari VCS/2600 - That's just an absolutely beautiful design in it's minimalism (had to be, to be useful and only ~$200). Ever coded for it? It makes even the Apple II seem enormously complex and powerful. It's sooo fun.
Feb 21 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
Thinking about globbing, I think rm * is a mistake
anyway...

The way I'd do programs is something like this:

echo input > program_name options....

So, you wouldn't rm *. You'd ls | rm.

You'd implement rm like this:
void main() {
      foreach(file; stdin.byLine)
          std.file.remove(file);
}


This way, options and things to operate on
are nicely separated, and you can process
the input with more filters easily.

glob * | grep 'poo' | rm

and etc.


Windows Powershell actually kinda works this way,
from what I know of it. You can do

ps | kill

and it works.



I almost *almost* want to write my own custom userland.
But, while I can complain all day about what we have...
meh it works well enough that I'm in no rush to spend
a lot of time replacing it.
Feb 21 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 23, 2012 at 10:34:24PM +0100, Adam D. Ruppe wrote:
 On Thursday, 23 February 2012 at 21:17:35 UTC, H. S. Teoh wrote:
Taking the idea of an in-terminal video player further, what about
a general escape sequence for "application-specific output"?

<html>.....

That gives you the funny situation where trying to edit a HTML file will interpret the tags instead of displaying them. If your editor is unaware of that, then you have the even funnier situation where editing a tag (i.e. temporarily breaking HTML syntax) will cause it to come out as text, and once you have a fully formed tag, then it magically gets rendered again. A twisted form of WYSIWYG. :P
 seriously, once you take the in-terminal stuff too far, you
 have a beast of a program that does everything; you end up
 with something like a web browser or nested X server, and
 you've lose the original beauty of the terminal.

No, the idea is *not* to have the terminal do everything, but allow other programs to do it.
 This is the path I started on, and ended up with what I called
 the D Windowing System - which is still on my todo list, but
 has been for a long time and will surely be for a long time
 more.

lol... I suppose.
 But, I started with a terminal that can optionally output
 images. Then wanted improved character display and figured
 if it does images, it can be a bitmap drawable.
 
 Then wanted multiple channels... and at this point, you have
 a poor man's X.

True.
 Realizing this, I went full into it and shifted gears to a higher
 level X kind of thing, where you make an app based on widgets on
 a grid, which would work in text mode or graphical mode. But, I
 didn't get too far before work took over my time.

Actually, I've thought of that before. It's something I'd love to have. The main complaint with writing a real X11 app is that *everything* is graphical, so to do something as simple as print a string requires an inordinate amount of code. You need to create a subwindow or subdrawable, load a font (with all that living nightmare that font resolution is), calculate font proportions, spacing, line wrapping, and do all of the above in an event-based model. At the end of the day you've reinvented a GUI toolkit with a text widget. [...]
 But, on a terminal, I just don't think images are a fit there.  Might
 as well just make something like a gui image viewer app and keep a
 more traditional terminal.
 
 Though, I'd prefer to be more like vga text mode than VT100 in terms
 of capabilities.

The way I see it, it's a sort of "VGA-enabled text mode" terminal, where you can intermix graphics on what is basically a character grid. Not a full-fledged windowing system embedded in xterm. (I mean, with graphics capabilities the application *could* implement a windowing system, but that's the app's problem, not the terminal's.) T -- One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"
Feb 23 2012
prev sibling parent James Miller <james aatch.net> writes:
On 24 February 2012 12:03, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 On Thu, Feb 23, 2012 at 10:34:24PM +0100, Adam D. Ruppe wrote:
 On Thursday, 23 February 2012 at 21:17:35 UTC, H. S. Teoh wrote:
Taking the idea of an in-terminal video player further, what about
a general escape sequence for "application-specific output"?

<html>.....

That gives you the funny situation where trying to edit a HTML file will interpret the tags instead of displaying them. If your editor is unaware of that, then you have the even funnier situation where editing a tag (i.e. temporarily breaking HTML syntax) will cause it to come out as text, and once you have a fully formed tag, then it magically gets rendered again. A twisted form of WYSIWYG. :P
 seriously, once you take the in-terminal stuff too far, you
 have a beast of a program that does everything; you end up
 with something like a web browser or nested X server, and
 you've lose the original beauty of the terminal.

No, the idea is *not* to have the terminal do everything, but allow other programs to do it.
 This is the path I started on, and ended up with what I called
 the D Windowing System - which is still on my todo list, but
 has been for a long time and will surely be for a long time
 more.

lol... I suppose.
 But, I started with a terminal that can optionally output
 images. Then wanted improved character display and figured
 if it does images, it can be a bitmap drawable.

 Then wanted multiple channels... and at this point, you have
 a poor man's X.

True.
 Realizing this, I went full into it and shifted gears to a higher
 level X kind of thing, where you make an app based on widgets on
 a grid, which would work in text mode or graphical mode. But, I
 didn't get too far before work took over my time.

Actually, I've thought of that before. It's something I'd love to have. The main complaint with writing a real X11 app is that *everything* is graphical, so to do something as simple as print a string requires an inordinate amount of code. You need to create a subwindow or subdrawable, load a font (with all that living nightmare that font resolution is), calculate font proportions, spacing, line wrapping, and do all of the above in an event-based model. At the end of the day you've reinvented a GUI toolkit with a text widget. [...]
 But, on a terminal, I just don't think images are a fit there. =C2=A0Mig=


 as well just make something like a gui image viewer app and keep a
 more traditional terminal.

 Though, I'd prefer to be more like vga text mode than VT100 in terms
 of capabilities.

The way I see it, it's a sort of "VGA-enabled text mode" terminal, where you can intermix graphics on what is basically a character grid. Not a full-fledged windowing system embedded in xterm. (I mean, with graphics capabilities the application *could* implement a windowing system, but that's the app's problem, not the terminal's.) T -- One reason that few people are aware there are programs running the inter=

rlying the internet is reliable to the point of invisibility. -- Glyn Moody= , from the article "Giving it all away" I have tried to keep the scope of what the graphics capabilities of the terminal are down to a minimum, so all the drawing would still be in terms of the terminal. I was thinking that you put it into graphics mode, say how many columns and rows you want, and the length of the data (so as to not accidentally leave image mode because the data contains the escape sequence for leaving image mode) It would start drawing in a rectangle from cursor location, and leave the cursor in the column after the last. I haven't decided what would happen if you didn't have enough columns (rows would just scroll), or how you'd deal with images that don't fit into character block pixel sizes. So you could implement a fully graphical system inside it, but it would be a lot of work, and you wouldn't have the advantage of any windowing features, and everything would still be cursor-based anyway. Basically the idea is to make it easy to implement features that make sense in a terminal, but make it difficult to do anything outside that scope. So I probably wouldn't have a subwindow, since that instantly provides way too much functionality, also you could output pictures fine simply by decoding the pictures into some "raw" format (preferably something that can be mapped straight to a pixbuf) and outputting them, video could work by just doing the same thing, but moving the cursor back to the original starting point over-and-over. Trying to make a graphical app would be a more of a challenge if you want anything remotely complicated, and you'd end up just using X anyway. I guess the idea is that being able to, for example, display pictures in your otherwise-terminal-based mail app is useful, being able to preview files without opening a new window (useful for people with tiling managers, like me) is useful. But having something that tries to be a window manager, or a proper app, is not useful. By having a layer of indirection, and the performance penalty that holds, trying to maintain terminal context, and making it unidirectional, it essentially forces apps to not abuse the capability, its not feasible to do anything other than just display an image. There are a few other idea I have, but aren't even close to being properly formed yet, however the simple-to-use graphics capabilities described above is something that I think has real merit. I've seen a few similar things in the past, but I don't think they tried to be a terminal emulator in their own right, so I couldn't run vim or screen in them.
Feb 23 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 08:53:06AM +0100, Paulo Pinto wrote:
[...]
 This has been changing in the last years since Microsoft introduced
 Powershell and due to market pressure created headless versions of
 Windows.

Wow. Headless Windows? Can it even be called Windows anymore? :) T -- IBM = I'll Buy Microsoft!
Feb 22 2012