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.

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

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

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.

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

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

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.

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.

> 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
> 

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.