Adding Unicode operators to D

[Bill Baxter]

On Sat, Oct 25, 2008 at 11:39 AM, Benji Smith <dlanguage at benjismith.net> wrote:
> Bill Baxter wrote:
>>
>> On Sat, Oct 25, 2008 at 10:31 AM, Benji Smith <dlanguage at benjismith.net>
>> wrote:
>>>
>>> Yigal Chripun wrote:
>>>>
>>>> Bill Baxter wrote:
>>>>>
>>>>> On Sat, Oct 25, 2008 at 9:15 AM, Sergey Gromov <snake.scaly at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Sat, 25 Oct 2008 06:43:19 +0900,
>>>>>> Bill Baxter wrote:
>>>>>>>
>>>>>>> On Sat, Oct 25, 2008 at 6:37 AM, ore-sama <spam at here.lot> wrote:
>>>>>>>>
>>>>>>>> Bill Baxter Wrote:
>>>>>>>>
>>>>>>>>> (like I haven't been able to figure out how to get the
>>>>>>>>> DOS console in Windows to display UTF-8)
>>>>>>>>
>>>>>>>> Console is a legacy technology (you even still call it "DOS"), why
>>>>>>>> expect features from it?
>>>>>>>
>>>>>>> So tell me what the alternative is?  I had trouble with running D
>>>>>>> tools from a Cygwin shell.  Can't remember if I tried MSYS or not.
>>>>>>>
>>>>>>> Anyone using a shell for Windows that works and supports UTF-8
>>>>>>> properly?
>>>>>>
>>>>>> A regular Windows console supports UTF-8 to some extent:
>>>>>>
>>>>>> * Change console font to Lucida Console
>>>>>> * issue "chcp 65001"
>>>>>>
>>>>>> You can even get more fonts into there with a bit of hackery.
>>>>>
>>>>> I did that but "type <filewith-utf8.txt>"  still prints garbage.
>>>>>
>>>>> --bb
>>>>
>>>> so don't use type. use notepad instead...
>>>> notepad <filewith-utf8.txt>
>>>> also, MSYS gives you all the linux tools if you really need to be shell
>>>> only.
>>>> last resort: nothing stops you from implementing your own "cat"
>>>> application in D with full Unicode support.
>>>>
>>>> most if not all linux shell tools are separate executables anyway and if
>>>> any still do not support unicode it'll be trivial to roll your own
>>>> replacements for the bad ones.
>>>
>>> Oh, and one of my favorite tricks in Windows is to install cygwin
>>> (usually
>>> at "C:\cygwin" or whatever their boneheaded installer insists on using)
>>> and
>>> then add the bin path ("C:\cygwin\bin") to the windows PATH.
>>>
>>> That way, I can continue using the ordinary windows shell (which I
>>> prefer,
>>> since it doesn't force me to use the nutty directory names that the
>>> cygwin
>>> shell uses), but I can still access all the linux commands.
>>>
>>> Calling grep from a windows shell is the bestest!
>>
>> But that has the same problem.  Cygtools don't understand windows
>> paths so barf when you say "grep c:\foo.txt"  But the Windows shell
>> only will only autocomplete Windows-style paths.
>>
>> I've found the gnuwin32 tools to work a little better on that front.
>>
>> --bb
>
> Wha???
>
> The "grep" tool doesn't read the path. The *shell* interprets the path and
> passes the text to the program. That's how all the gnu tools are able to
> pipe their results from one tool to the other.
>
> Or at least, that's how I assume it works.
>
> Cuz I use grep like every single day. On the "cmd.exe" shell. With windows
> paths.
>
> In fact, just for you, I tested this:
>
>   grep -i "SHAZZAM" "C:\Documents and Settings\benji\Desktop\my filename
> with spaces.txt"
>
> Worked like a charm.
>
> If the path doesn't have spaces, I have no problem with this:
>
>   grep -i "SHAZZAM" C:\file.txt
>
> I tried it in both "command.com" and in "cmd.exe" and didn't experience any
> problem in either environment.
>
> The key is to never never never use the cygwin shell. It's a piece of
> garbage. But using the executables from the "cygwin\bin" directory within
> the windows shell... Priceless!

Oh, I didn't realize that.  There is one thing that doesn't work,
which is probably what gave me the impression it was broken -- Windows
paths with wildcards don't work.   Like "grep c:\Windows\*.txt".   But
you're right that it does seem to work for both windows paths, and
local wildcards, just not Windows paths with wildcards.

But that's great.  Thanks for the info.  Actually I used to put
cygwin\bin on my path years ago, but stopped doing it at some point
and switched to gnuwin32.  I was under the impression that it worked
better then, but actually I've had some trouble with gnuwin32
recently.

--bb