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=


e

 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
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 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 "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
parent reply "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
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
parent reply "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
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 "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
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
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 parent reply "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
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 =


only meant

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


is also installed.

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


news:jhupcv$2l7j$1 digitalmars.com...

=20
 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".


=20
 Oh, certainly!


=20
 Rats. I was hoping the boys in Redmond have improved the situ since.
=20
 Andrei=20
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 reply "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
parent reply "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
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
next sibling parent reply "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
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 parent reply "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
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 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 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 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 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 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 "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 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
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 parent reply "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
parent reply "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:


$ cd evil-unix


$ ls
-l  cool

-rw-r--r-- 1 me users 0 2012-02-20 22:18 cool
$


imagine the poor newb trying to understand that!
Feb 20 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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:
 

 $ cd evil-unix


 $ ls
 -l  cool

 -rw-r--r-- 1 me users 0 2012-02-20 22:18 cool
 $
 
 
 imagine the poor newb trying to understand that!


+1, LOL.


T

-- 
Two wrongs don't make a right; but three rights do make a left...
Feb 20 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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!
Feb 20 2012
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 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:


 $ cd evil-unix


 $ ls
 -l  cool

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


 $ cd evil-unix


 $ ls
 -l  cool

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


 $ cd evil-unix


 $ ls
 -l  cool

 -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 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 reply "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
parent reply "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:



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
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 05:56:49AM +0100, Adam D. Ruppe wrote:
[...]

 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.


Ahh, good ole days of hacking 2D graphics by coding in assembly
language. I loved it. In fact, I date back to the good ole days of Apple
II (not the IIe, the original Apple II). They used to have this CP/M
card with a ROM that can be swapped in to the built-in Apple ROM's
memory address (IIRC, E800-FFFF or something to that effect). This "ROM"
is actually writable via an address mapping to another range, I used to
fool around by writing my own OS-level code and then swapping it into
the ROM address, just to see what it would do. :)



 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 hated it. I hated it *so* much, I swore myself off windows 95 several
times at least. It was only after discovering Linux that I found the
concept of protected mode palatable, and even useful. That was after I
swore off Windows 95 for the last time. :P


[...]

I almost never download binaries, only source.


 
 Me too, which is kinda sad when distributing software.


Yeah.



 I like sharing my apps with Windows users because
 I can say "grab this exe and have fun".


True.

Until you run into DLL Hell. :P  For small apps this tends not to be a
problem, though. You can always just bundle the dll with your exe. Ugly,
but makes things work at the user's end.



 With Linux users, there's always some list of third
 party stuff they need too. dmd, qt, whatever, but
 always something.


Yeah. That's why I greatly prefer to use my distro's packaging system,
'cos of the automatic dependency fetching. In the bad ole days, it used
to go something like this:

- Oooh, my distro has software X! Lemme download the package!
- Hmm, it doesn't install. Says it's missing library Y.
- OK, no problem, let's download library Y's package from the distro.
- Oops, library Y needs library Z and library W. OK, no prob, get those
  too.
- Hmm, library W needs library V, and library Z needs library U. I guess
  I need those too.
- Oh, library U needs library T? Let's see, what does library T need?
  Oh, it needs library R and library S, and libraries R and S needs like
  20 other libraries once you chase down all the dependencies?
- Arghhh!! All this huge pile of libraries don't fit on my floppy disk
  anymore! Now I have to make two trips to the university's lab!

And this is if all goes well. When you start running into conflicting
versions, it all goes down the pipes real fast.


[...]

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


I use ratpoison. C-t c, get new terminal. Done with it, C-t k dismisses
it. Won't go away? Stuck infinite loop? C-t K forcefully terminates its
X11 connection. That usually fixes it. If not, there's always kill -9.
:-)


[...]

 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.


Really? I tried that once. I never dared try it again. Almost 99% of all
windows apps assume the usual focus. Sloppy focus just screws up their
UI assumptions in subtle ways that eventually just makes everything a
total pain to use.

I've found that when using Windows (and other MS products), you just
have to follow along with it and do things its way. Trying to customize
it is an exercise in masochism.

Of course, in Linux things are a bit *too* customizable. Which is heaven
for the power user, hell for the non-distro software distributor ("I
have to support *how* many different versions of libc and libqt in *how*
many different permutations?!"). I still occasionally have Firefox
coughing up blood when I insist on having no Desktop subdirectory under
my home directory. :)



 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.


Ah yes, I learned this the hard way when I tried to enable sloppy focus
that one time. Eventually I decided that it's just not worth the pain.
Just let Windows have its way. As long as I have putty, I'm happy. :)


T

-- 
Meat: euphemism for dead animal. -- Flora
Feb 21 2012
prev 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 "$" 


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:



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


 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

"$ " > /dev/null 2> /dev/null &

$ cat ~/bin/guisudo

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 reply "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
next sibling parent reply "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
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
next sibling parent reply "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!


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
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 parent reply "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
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 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
next sibling parent reply "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
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 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 reply "Bernard Helyer" <b.helyer gmail.com> writes:
Nick replied to something about globbing


Having programs doing the globbing sounds great until you run 
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
parent reply "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


 Having programs doing the globbing sounds great until you run 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 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
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:


	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 reply "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:


 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
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 parent reply "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:


 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




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



 
 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

	$



 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 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 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
parent reply "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
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
parent reply "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




	abcdef



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
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
parent reply "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
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
next 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 "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 next sibling parent reply "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
parent reply "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
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 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=


s

 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 parent reply "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
parent reply "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
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 next 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=




ht

 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=


net is that they never crash in any significant way: the free software unde=
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 reply "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
parent reply "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
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 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 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 parent reply "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
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 reply "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
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 reply "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
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 21, 2012 at 08:09:49PM -0500, Nick Sabalausky wrote:

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




[...]

 Heh, as bad as this might sound, I think what I basically want is
 more or less Windows Explorer on linux ;) 






[...]

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


Only true for the old guard, hardcore people like myself. Newer Linux
users tend to like their GUI desktops better. Even if they do use the
command-line every now and then. In another generation or two I don't
think many of the old guard people will be left.



 But it's looking like Vlad's D forums might be on their way to being
 D's killer app anyway ;)


Well in that case, we'd better get our act together and produce more
awesome D apps, so that when D starts hitting the media headlines and
people start searching for us, we'd have something to show for it
besides saying "oh, D forums, that's the only really significant thing
we've done so far". :)


[...]

 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.


I believe it too. The man's a bona fide genius.

Man I love those old days when I spent hours memorizing assembly opcodes
just to... no, wait, I didn't *deliberately* memorize them, it was just
that I coded in assembly so much I could memorize almost all of the
common instructions.  Yikes. Where did my childhood go?! :P



 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.


[...]

OK, you beat me there. I never owned an Atari. :(

But yeah, even the Apple II had its complexities.

I still remember puzzling over how Apple DOS can somehow "magically" add
DOS commands to the BASIC prompt without the BASIC interpreter even
knowing anything about DOS. Until one day I discovered that Apple DOS
was hooking into the *keyboard interrupt vector* and listening in on
keystrokes to sent to the BASIC interpreter's command line. When it saw
a newline, it checked to see if the command buffer contained a DOS
command. If not, it lets the newline through and the BASIC interpreter
interpreted the command. But if the buffer contained a DOS command, the
newline would be swallowed by DOS, which then proceeds to run the
command before erasing the buffer and returning to the BASIC
interpreter, as if no command had ever been typed.

Apple DOS also hooked into the console output vector to catch those
programmatic DOS commands which you put in your programs by doing
something like: PRINT;PRINT ^DBRUN FILE;PRINT. The magic sequence was
newline followed by ctrl-D followed by DOS command.  Such output
sequences were "stolen" from the ROM's output routines and put in a
temporary buffer, so that instead of being written to screen they ran a
DOS command at the next newline.

It was clever tricks like these that inspired me to become a programmer.


T

-- 
It won't be covered in the book. The source code has to be useful for
something, after all. -- Larry Wall
Feb 21 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.842.1329878177.20196.digitalmars-d puremagic.com...

 On Tue, Feb 21, 2012 at 08:09:49PM -0500, Nick Sabalausky wrote:

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




 [...]

 Heh, as bad as this might sound, I think what I basically want is
 more or less Windows Explorer on linux ;)






 [...]

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


 Only true for the old guard, hardcore people like myself. Newer Linux
 users tend to like their GUI desktops better. Even if they do use the
 command-line every now and then. In another generation or two I don't
 think many of the old guard people will be left.


Good point.


 But it's looking like Vlad's D forums might be on their way to being
 D's killer app anyway ;)


 Well in that case, we'd better get our act together and produce more
 awesome D apps, so that when D starts hitting the media headlines and
 people start searching for us, we'd have something to show for it
 besides saying "oh, D forums, that's the only really significant thing
 we've done so far". :)


Absolutely :)


 Man I love those old days when I spent hours memorizing assembly opcodes
 just to... no, wait, I didn't *deliberately* memorize them, it was just
 that I coded in assembly so much I could memorize almost all of the
 common instructions.  Yikes. Where did my childhood go?! :P


Heh yea. If I'm lacking in social skills, I think growing up on the Apple 
IIc and 386/486 are most likely to blame ;)


 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.


 [...]

 OK, you beat me there. I never owned an Atari. :(


I never did either until about 10 years ago when I spotted a nearly-new 
2600jr in a second-hand games store and quickly snatched it up.

There's a lot of great information on the web for how the 2600 worked, and 
how to develop for it. You can even get cheap cartridges that you pop in an 
EEPROM with your code and then run on the physical machine instead of just 
an emulator.

I read up on that information and wrote one little program for it. Wasn't a 
full-fledged game or anything, just a single-screen playfield you could move 
round in and interact with. I even designed and wired up a (barely-working) 
Parallel Port EEPROM burner, burnt the image, popped it into one of those 
homebrew carts you can get, and had it running on the real thing. I *should* 
still have the ROM image and source around somewhere, I'll have to dig them 
out. I know it'll run on the Stella emulator.

I miss having time for console homebrew, it's incredibly satisfying. I used 
to do a bit on the GBA, too: Check the "Older stuff:" section at the bottom 
of http://www.semitwist.com/ The ROMs will run in the fantastic VisualBoy 
Advance emulator (or on actual hardware, if you have the right Chinese 
gadgets ;) ).



 But yeah, even the Apple II had its complexities.

 I still remember puzzling over how Apple DOS can somehow "magically" add
 DOS commands to the BASIC prompt without the BASIC interpreter even
 knowing anything about DOS. Until one day I discovered that Apple DOS
 was hooking into the *keyboard interrupt vector* and listening in on
 keystrokes to sent to the BASIC interpreter's command line. When it saw
 a newline, it checked to see if the command buffer contained a DOS
 command. If not, it lets the newline through and the BASIC interpreter
 interpreted the command. But if the buffer contained a DOS command, the
 newline would be swallowed by DOS, which then proceeds to run the
 command before erasing the buffer and returning to the BASIC
 interpreter, as if no command had ever been typed.

 Apple DOS also hooked into the console output vector to catch those
 programmatic DOS commands which you put in your programs by doing
 something like: PRINT;PRINT ^DBRUN FILE;PRINT. The magic sequence was
 newline followed by ctrl-D followed by DOS command.  Such output
 sequences were "stolen" from the ROM's output routines and put in a
 temporary buffer, so that instead of being written to screen they ran a
 DOS command at the next newline.

 It was clever tricks like these that inspired me to become a programmer.


Heh, I think you got waaay beyond where I ever got in understanding the 
Apple II's internals.
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 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 reply Manu <turkeyman gmail.com> writes:
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.
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 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