Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #106122 > unrolled thread

More problems with lcc-win

Back to article view | Back to comp.lang.c

Contents

  More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 00:29 -0700
    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 11:27 +0100
      Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 13:18 +0000
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 15:22 +0100
          Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 08:26 -0700
      Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 08:25 -0700
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 16:46 +0100
          Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-15 17:07 +0100
            Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 09:52 -0700
              Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 16:57 +0000
                Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 10:11 -0700
                  Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 18:17 +0000
              Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 17:21 +0000
                Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-15 18:42 +0100
                  Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 18:20 +0000
                    Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 18:59 +0000
                  Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-15 18:20 +0000
                    Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-15 19:39 +0100
                    Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 12:44 -0700
                      Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-15 20:19 +0000
                        Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 10:03 +0100
                          Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-16 11:15 +0000
                            Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-16 11:32 +0000
                            Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 13:41 +0100
                    Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-16 08:52 +0100
                    Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 09:57 +0100
                  Re: More problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-16 13:53 +0000
                    Re: More problems with lcc-win jm.bourguet@gmail.com - 2017-03-16 07:14 -0700
                    Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-16 08:59 -0700
                Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 12:43 -0700
                  Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 20:39 +0000
              Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:56 +0100
          Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 16:33 +0000
            Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 17:47 +0100
              Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 10:04 -0700
                Re: More problems with lcc-win jacob navia <jacob@jacob.remcomp.fr> - 2017-03-16 00:52 +0100
                  Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 18:02 -0700
                    Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 18:23 -0700
                      Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-17 13:45 -0700
                        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:23 +0100
                          Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:29 +0100
                            Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:31 +0100
                            Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-17 17:01 -0700
                              Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-20 16:41 +0000
                                Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-20 18:32 +0100
                                  Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-20 18:18 +0000
                                    Re: More problems with lcc-win bart4858@gmail.com - 2017-03-20 12:31 -0700
                                      Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-20 21:05 +0100
                                        Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-20 20:45 +0000
                                      Re: More problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-20 20:18 +0000
                                      Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-21 09:56 +0100
                                        Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-21 21:08 +0000
                                          Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-21 22:19 +0100
                                            Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-22 06:29 +0000
                                          Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-21 16:12 -0700
                                            Re: More problems with lcc-win gordonb.s97bd@burditt.org (Gordon Burditt) - 2017-03-24 01:13 -0500
                                              Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-24 08:16 -0700
                                            Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-26 03:18 -0700
                                              Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-26 12:35 +0100
                                                Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-29 05:17 -0700
                                              Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-26 14:04 -0700
                                                Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-29 05:48 -0700
                                          Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-21 23:21 +0000
                                            Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-22 06:18 +0000
                                          Re: More problems with lcc-win gordonb.1neik@burditt.org (Gordon Burditt) - 2017-03-21 18:45 -0500
                                          Re: More problems with lcc-win jm.bourguet@gmail.com - 2017-03-22 01:02 -0700
                                          Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-22 10:35 +0100
                                          Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-22 13:21 +0000
                                            Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-22 14:08 +0000
                                              Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-22 15:37 +0000
                                          Re: More problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-22 21:09 +0000
                                      Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 13:09 +0000
                                        Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-21 21:15 +0000
                          Re: More problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-18 12:44 +1300
                          Re: More problems with lcc-win jameskuyper@verizon.net - 2017-03-17 16:59 -0700
                        Re: charsets Noob <root@127.0.0.1> - 2017-03-18 18:30 +0100
                  Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 10:18 +0100
              Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 15:06 -0700
                Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 22:23 +0000
                  Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 15:43 -0700
                    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:53 +0100
                      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-16 08:35 -0700
                    Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 23:13 +0000
                      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-16 06:28 -0700
                        Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-16 16:56 +0000
                          Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-16 14:53 -0700
                Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 16:18 -0700
                  Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-16 18:03 +0000
                    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-16 19:29 +0100
                      Re: More problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-16 21:38 +0000
                      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-17 08:58 -0700
                  Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-17 09:45 -0700
                    Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-17 10:33 -0700
                      Re: More problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-17 14:20 -0400
                      Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-17 20:18 +0100
                        Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 00:44 -0700
                          Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-18 13:31 +0000
                            Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 15:54 -0700
                            Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-20 13:27 +0000
                          Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-18 15:15 +0100
                            Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 11:39 -0700
                              Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-18 20:11 +0100
                                Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-18 19:45 +0000
                                  Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-20 00:35 -0700
                                Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 14:22 -0700
                                  Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-18 22:46 +0100
                                    Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 16:12 -0700
                                    Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-18 18:01 -0700
                                      Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 03:21 +0100
                                        Re: More problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-19 15:32 +1300
                                      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-19 02:17 -0700
      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:25 -0700
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:49 +0100
    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 11:28 +0100
      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:35 -0700
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:44 +0100
    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 13:06 +0100
      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:43 -0700
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:43 +0100
    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 13:19 +0100
      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:50 -0700
    Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 08:24 -0700
      Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 16:47 +0100
        Re: More problems with lcc-win jameskuyper@verizon.net - 2017-03-15 09:04 -0700
        Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 09:15 -0700
          Re: More problems with lcc-win gazelle@shell.xmission.com (Kenny McCormack) - 2017-03-15 19:59 +0000
        Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 16:32 +0000

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

#106406

Le 18/03/2017 à 00:23, jacobnavia a écrit :
>
> Look I am sending you the message from
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
>  Gecko/20100101 Thunderbird/45.8.0
>
> Why should I use a windows charset?
>
> Because Thunderbird defaults in the news server to encoding in
> "Occidental". You have along list of languages (arab, chines whatever)
> and then "Occidental", what was the default.
>
> And look what?
>
> "Occidental" means in thunderbird "windows"!!!
>
> Mystery solved. I changed the encoding to UTF8, and maybe it will be
> better.
>

No that was the wrong explanation. I have other message sent here using 
utf8. Apparently, when I answer in a thread where somebody used windows 
charset, thunderbird will default to the charset I am replying to.

Looking at this thread I noticed that Richard Heathfield has this header:
Content-Type: text/plain; charset=windows-1252; format=flowed

Then thunderbird passes into windows charset, so you should explain this 
stuff to Richard...

[toc] | [prev] | [next] | [standalone]

#106407

Le 18/03/2017 à 00:29, jacobnavia a écrit :
>
> Then thunderbird passes into windows charset, so you should explain this
> stuff to Richard...

The message id of Richard's post is:
<oabq7l$rr1$2@dont-email.me>

[toc] | [prev] | [next] | [standalone]

#106414

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 18/03/2017 à 00:23, jacobnavia a écrit :
>> Look I am sending you the message from
>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
>>  Gecko/20100101 Thunderbird/45.8.0
>>
>> Why should I use a windows charset?
>>
>> Because Thunderbird defaults in the news server to encoding in
>> "Occidental". You have along list of languages (arab, chines whatever)
>> and then "Occidental", what was the default.
>>
>> And look what?
>>
>> "Occidental" means in thunderbird "windows"!!!
>>
>> Mystery solved. I changed the encoding to UTF8, and maybe it will be
>> better.
>>
>
> No that was the wrong explanation. I have other message sent here
> using utf8. Apparently, when I answer in a thread where somebody used
> windows charset, thunderbird will default to the charset I am replying
> to.
>
> Looking at this thread I noticed that Richard Heathfield has this header:
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Then thunderbird passes into windows charset, so you should explain
> this stuff to Richard...

Your message that I'm currently replying to uses UTF-8.  Some other
messages used windows-1252.  Maybe it's inherited from earlier messages
somehow?

Yes, I've noticed that (at least some of) Richard's messages also use
windows-1252.  It hasn't caused an issue for me because his messages
tend not to have non-ASCII accented letters, and yours, quite
understandably, do.  (The problem is that Gnus complains when I post a
followup that contains non-ASCII characters -- but it doesn't seem
to happen consistently.  In fact I think I've seen it happen and not
happen when posting followups to the same article.  Weird.)

Is it possible that your message <oack40$1n5b$1@gioia.aioe.org> actually
had charset=windows-1252 when it left your newsreader, even though it
appeared on your end to have charset=utf-8?  It has charset=windows-1252
when I read it on aioe.org.  (In my newsreader that header isn't
generated until I post.)

If I run into the problem again, there's a Gnus configuration setting I
can try.  I'll report if it works.  If not, there's probably no need to
take up more bandwidth with this.

Thanks.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#106588

On 18/03/17 00:01, Keith Thompson wrote:
<snip>
> Yes, I've noticed that (at least some of) Richard's messages also use
> windows-1252.

Keith, I meant to reply to your article here but I appear to have sent 
it via email instead, for which I apologise. (I only discovered this 
when the article continued not to turn up in the newsfeed.)

On digging around in my newsreader's options, I discovered that it was 
indeed sending in windows-1252, which is bizarre because it's never been 
anything other than a Linux system (it was bought from a company called 
The Linux Emporium!). I've now told Thunderbird in no uncertain terms 
not to do the Windows encoding thing, but whether it obeys is another 
matter.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#106593

Le 20/03/2017 à 17:41, Richard Heathfield a écrit :
> I discovered that it was indeed sending in windows-1252, which is
> bizarre because it's never been anything other than a Linux system

My Thunderbird is under Mac OS X since 2010... But you can't get rid of 
windows anyway.

[toc] | [prev] | [next] | [standalone]

#106596

On 20/03/17 17:32, jacobnavia wrote:
> Le 20/03/2017 à 17:41, Richard Heathfield a écrit :
>> I discovered that it was indeed sending in windows-1252, which is
>> bizarre because it's never been anything other than a Linux system
>
> My Thunderbird is under Mac OS X since 2010... But you can't get rid of
> windows anyway.

A man can dream, can't he?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#106601

On Monday, 20 March 2017 18:18:19 UTC, Richard Heathfield  wrote:
> On 20/03/17 17:32, jacobnavia wrote:
> > Le 20/03/2017 à 17:41, Richard Heathfield a écrit :
> >> I discovered that it was indeed sending in windows-1252, which is
> >> bizarre because it's never been anything other than a Linux system
> >
> > My Thunderbird is under Mac OS X since 2010... But you can't get rid of
> > windows anyway.
> 
> A man can dream, can't he?

A world dominated by Unix, Linux, Bash, configure, shell commands, wildcard expansions, casE sensitive (case sensitive for those who .. never mind), /etc, root, C language+gcc+Linux so tightly bound together you cannot prise them apart, auto-conf tools, appallingly bad keyboard support, a million different distributions, a hundred different desktop GUIs - or none at all.....?

More like the stuff of nightmares. If it happened, then time to give up programming and do more work in the garden I think.

(Is creating an OS - something to provide file services and to offer a common interface to display, keyboard, printer, and to launch executables etc - so massively difficult a task then every new one /has/ to be based on Unix?)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#106603

Le 20/03/2017 à 20:31, bart4858@gmail.com a écrit :
> A world dominated by Unix, Linux, Bash, configure, shell commands,

wildcard expansions, casE sensitive (case sensitive for those who ..

never mind), /etc, root, C language+gcc+Linux so tightly bound together

you cannot prise them apart, auto-conf tools, appallingly bad keyboard

support, a million different distributions, a hundred different desktop

GUIs - or none at all.....?

THAT is nothing compared to a system that is designed to serve you ads
constantly, that takes over your machine and it is no longer your 
machine but YOU are an advertising revenue of someone else.

Your machine OS owns you.

For instance slashdot tells that even if you say to the system that you 
do not want any updates, microsoft will download updates anyway because 
too many people were shutting off updates by telling windows that they 
are in a metered connection.

You are no longer in control of the OS, or your machine, or whatever.

You have been sold.

I am ready to accept linux, bash, (that is far better than cmd excuse 
me) and configure. You are crying again like a small baby.

You do not like the file system being case sensitive? Use a mac. No case 
sesitivity there. And maybe you can turn that off in linux file system, 
since if you format a drive as NTFS you will get a case unsensitive file 
system under linux, that has a good NTFS implementation. Or even ext4 
can do that, I do not care so much.

I do not see anything wrong with the system being bound to the C 
language, and the keyboard support is the same as windows, as far as I 
can see.

The "million distributions" I see it as an advantage: there is no 
monolithic, central company that owns it. There are a lot of versions 
and all are quite incompatible. Very good, nobody controls it.

Yes, there are many guis, so just use one and stick to it. I am using 
linux mint desktop, that is very nice. A good desktop because it is not 
spying on me, and hasn't a lot of unneeded "bells and whistles" 
everywhere. It is quite spartan looking, but it is easy to use, and you 
find easily what you want to do.

Above all, it is a desktop machine. You can customize your computer and 
it will do what you tell it to do. If you do not want updates you 
update nothing and everything will go on working as usual. It will not 
sell you to somebody else, since I did not subscribe to any "cloud", I 
am not in facebook, twitter or whatever.

[toc] | [prev] | [next] | [standalone]

#106608

On 20/03/2017 20:05, jacobnavia wrote:
> Le 20/03/2017 à 20:31, bart4858@gmail.com a écrit :
>>" A world dominated by Unix, Linux, Bash, configure, shell commands,
>
> wildcard expansions, casE sensitive (case sensitive for those who ..
>
> never mind), /etc, root, C language+gcc+Linux so tightly bound together
>
> you cannot prise them apart, auto-conf tools, appallingly bad keyboard
>
> support, a million different distributions, a hundred different desktop
>
> GUIs - or none at all.....?"
>
> THAT is nothing compared to a system that is designed to serve you ads
> constantly, that takes over your machine and it is no longer your
> machine but YOU are an advertising revenue of someone else.
>
> Your machine OS owns you.

I'm still on Windows 7 for the time being, and I don't get much of that. 
As far as updates are concerned, you will get that on Linux every time 
you install or upgrade any app, as these will all trigger updates across 
many applications.

> I am ready to accept linux, bash, (that is far better than cmd excuse
> me) and configure. You are crying again like a small baby.

My point was about the lack of diversity if one major OS were to disappear.

But does it have to be Windows versus Unix? With the latter lurking 
everywhere under its alter-egos (isn't OSX based on it too?).

> You do not like the file system being case sensitive? Use a mac. No case
> sesitivity there. And maybe you can turn that off in linux file system,

Every time I complain about some detail in Linux, I'm told I can do X to 
get around it. But I need to do X every time. To make it persistent, I 
have to do Y. But that will interfere with Z.

And that's just on my machine. If I wanted to send someone else my app, 
then *they* will have to do X and Y too, but they might have other apps 
that require the opposite! So now they have to do W to ensure each app 
sets up its own environment.... And as always happens, you have to stop 
doing something useful and end up spending all time your reconfiguring 
Linux.

> since if you format a drive as NTFS you will get a case unsensitive file
> system under linux, that has a good NTFS implementation. Or even ext4
> can do that, I do not care so much.
>
> I do not see anything wrong with the system being bound to the C
> language, and the keyboard support is the same as windows, as far as I
> can see.

In X-windows perhaps. In terminal mode, keyboard support (and cursor 
positioning etc) is poor, and inconsistent and variable across Linux 
versions.

Windows also needs you to use Win32 to get things done, but you know 
that every Windows system will have the API functions available.

But ideally there would be a lightweight OS - not Linux - where this 
stuff just works effortlessly.

The CP/M-like OS I was using in the early eighties took 1.5 seconds** 
from pressing hard-reset to being able to start typing and getting 
things done. And that was booting from floppy on a 4MHz Z80.

My Raspberry Pi with 700MHz ARM takes 1-2 minutes, booting Debian from 
SD card. Perhaps Linux isn't quite as lightweight as people like to think...

(** Until they modified the OS, and maybe messed with the disk 
interleaving, then it took 4 seconds. Still, my Android tablet takes 2-3 
*minutes* to boot from cold. Enough that you leave it, forget about it, 
and discover it hours later with 1/4 the charge already gone.)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#106606

bart4858@gmail.com writes:

<snip>
> (Is creating an OS - something to provide file services and to offer a
> common interface to display, keyboard, printer, and to launch
> executables etc - so massively difficult a task then every new one
> /has/ to be based on Unix?)

It's unlikely that many people would settle for as little as that.  Of
course your conclusion is wrong since not all new OSes are or have been
based on Unix.

But Unix certainly is a popular starting point because there are open
source implementations, notably GNU/Linux and FreeBSD.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#106643

On 20/03/17 20:31, bart4858@gmail.com wrote:
> On Monday, 20 March 2017 18:18:19 UTC, Richard Heathfield  wrote:
>> On 20/03/17 17:32, jacobnavia wrote:
>>> Le 20/03/2017 à 17:41, Richard Heathfield a écrit :
>>>> I discovered that it was indeed sending in windows-1252, which
>>>> is bizarre because it's never been anything other than a Linux
>>>> system
>>> 
>>> My Thunderbird is under Mac OS X since 2010... But you can't get
>>> rid of windows anyway.
>> 
>> A man can dream, can't he?
> 
> A world dominated by Unix, Linux, Bash, configure, shell commands,
> wildcard expansions, casE sensitive (case sensitive for those who ..
> never mind), /etc, root, C language+gcc+Linux so tightly bound
> together you cannot prise them apart, auto-conf tools, appallingly
> bad keyboard support, a million different distributions, a hundred
> different desktop GUIs - or none at all.....?
> 
> More like the stuff of nightmares. If it happened, then time to give
> up programming and do more work in the garden I think.
> 

A world dominated by /any/ single OS is the stuff of nightmares.
Variety and competition leads to progress, innovation, and swapping
inspiration and ideas between systems.  Windows copies freely from MacOS
and *nix (though it took them 20 years to realise that IT professionals
need a decent command line, and 30 years to realise that virtual
desktops are useful), just as MacOS and *nix copy ideas from Windows and
each other.

But of all your rants above, the one I cannot comprehend is "bad
keyboard support".  Here are a few things I can type directly with my
keyboard in Linux that I cannot do with Windows (I've got a Norwegian
keyboard layout, so both systems can write ÅØÆ):

naïve café
a₃·x³ + a₂·x² + a₁·x = ¼
2πr²
1…5
1·2·3
ΩŁ¢™Þ¥↑ıŒºÐªŊĦŁ¾«»©“”µ±°¿¬÷⅝‰¶ßðđŋħĸł
ŝñèç♥

And if I want to change them, or add new keys, it's just a simple change
to a text file.

[toc] | [prev] | [next] | [standalone]

#106712

On Tue, 2017-03-21, David Brown wrote:
> On 20/03/17 20:31, bart4858@gmail.com wrote:
...
>> A world dominated by Unix, Linux, Bash, configure, shell commands,
>> wildcard expansions, casE sensitive (case sensitive for those who ..
>> never mind), /etc, root, C language+gcc+Linux so tightly bound
>> together you cannot prise them apart, auto-conf tools, appallingly
>> bad keyboard support, a million different distributions, a hundred
>> different desktop GUIs - or none at all.....?
>> 
>> More like the stuff of nightmares. If it happened, then time to give
>> up programming and do more work in the garden I think.
>
> A world dominated by /any/ single OS is the stuff of nightmares.
> Variety and competition leads to progress, innovation, and swapping
> inspiration and ideas between systems.  Windows copies freely from MacOS
> and *nix (though it took them 20 years to realise that IT professionals
> need a decent command line, and 30 years to realise that virtual
> desktops are useful), just as MacOS and *nix copy ideas from Windows and
> each other.

Some of us Unix fiends would prefer if that competition came from some
new, /interesting/ OS, and wasn't based on monopoly-like situations.

> But of all your rants above, the one I cannot comprehend is "bad
> keyboard support".  Here are a few things I can type directly with my
> keyboard in Linux that I cannot do with Windows (I've got a Norwegian
> keyboard layout, so both systems can write ÅØÆ):
...
>
> And if I want to change them, or add new keys, it's just a simple change
> to a text file.

I suspect you're not talking about x.org's XKB, which almost drove me
crazy trying to understand it well enough to add a few things[0].

And I still haven't figured out how to let each user choose her keymap,
without using one of those Windows-like desktop environments.

Still wouldn't call it "appallingly bad keyboard support" though. I
wonder what Bart is referring to.

/Jorgen

[0] More things than I wanted to/could add via xmodmap(1). I use an
    English layout, but with the latin-1 extras and some other symbols
    on Alt-<key>, like the xterm eightBitInput option.

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#106714

Le 21/03/2017 à 22:08, Jorgen Grahn a écrit :

>
> And I still haven't figured out how to let each user choose her keymap,
> without using one of those Windows-like desktop environments.
>
>

What do you think about:
https://superuser.com/questions/290115/how-to-change-console-keymap-in-linux

Doesn't look very complicated.

[toc] | [prev] | [next] | [standalone]

#106743

On Tue, 2017-03-21, jacobnavia wrote:
> Le 21/03/2017 à 22:08, Jorgen Grahn a écrit :
>
>>
>> And I still haven't figured out how to let each user choose her keymap,
>> without using one of those Windows-like desktop environments.
>>
>>
>
> What do you think about:
> https://superuser.com/questions/290115/how-to-change-console-keymap-in-linux
>
> Doesn't look very complicated.

It's not the console keymap I'm primarily interested in, but the X11
one.

In current Debian, that's replaced(?) by keyboard(5) which reuses the
XKB config.  Which is nice, because you define your keyboard once, and
it applies in both the console and in X11.

But that's one file, consulted at boot time, and it applies system-wide.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#106718

On Tuesday, March 21, 2017 at 4:08:21 PM UTC-5, Jorgen Grahn wrote:
> Still wouldn't call it "appallingly bad keyboard support" though. I
> wonder what Bart is referring to.

MS-DOS, CP/M, and other microcomputer operating systems have separate
functions to read a keystroke versus reading line-buffered input.  Unix
can kludge that by switching a terminal to "raw" mode, but the microcomputer
approach defers the decision about how input will be processed until code
gets around to processing it.  In MS-DOS, if a program outputs a prompt,
reads a character without echo, outputs another prompt, and reads a line,
the first character will not echo to the console, and the line of input will
echo following the second prompt.  This behavior will occur even if the user
typed the characters before the program began execution.

Is there any way to achieve comparable behavior in a Unix console application?

[toc] | [prev] | [next] | [standalone]

#106872

> MS-DOS, CP/M, and other microcomputer operating systems have separate
> functions to read a keystroke versus reading line-buffered input.  Unix
> can kludge that by switching a terminal to "raw" mode, but the microcomputer
> approach defers the decision about how input will be processed until code
> gets around to processing it.  In MS-DOS, if a program outputs a prompt,
> reads a character without echo, outputs another prompt, and reads a line,
> the first character will not echo to the console, and the line of input will
> echo following the second prompt.  This behavior will occur even if the user
> typed the characters before the program began execution.
> 
> Is there any way to achieve comparable behavior in a Unix console application?

Yes, but you won't like it.

1.  Turn echo OFF.  Leave it off.  You probably also need "raw" mode.
2.  When you read data that should be echoed, echo it then (so typeahead
    echos when it's actually read by the program that's going to use it).

Lots of screen editors work this way because the timing of typeahead
tends to break up cursor-positioning sequences being output in
response to previous input being processed, resulting in a complete
mess on the screeen if they let the drivers do the echoing.  Also,
control characters used as editor commands should *NOT* be echoed
if there is a chance that they will make the terminal react badly
(it is likely you need to (a) redraw some part of the screen and
(b) reposition the cursor).  

There are so many different terminal types that it's pretty much
certain that whatever a control character (or arrow key sequence,
etc.) is assigned to DO, some terminal will do the wrong thing.

A big problem is that none of the shells work this way, and typing
commands blind is rather error-prone.  It appears that the poster
prefers that typeahead be typed blind, which I'm not sure is a good
idea especially for complicated command lines.

[toc] | [prev] | [next] | [standalone]

#106929

On Friday, March 24, 2017 at 1:13:30 AM UTC-5, Gordon Burditt wrote:
> A big problem is that none of the shells work this way, and typing
> commands blind is rather error-prone.  It appears that the poster
> prefers that typeahead be typed blind, which I'm not sure is a good
> idea especially for complicated command lines.

If a terminal has a mode which handles editing locally until enter/return
is pressed, whereupon an entire line is transmitted, that may be ideal if
one is typing characters ahead of when they will be processed.  Having
keyboard characters echo while running a program that isn't going to produce
any output might better than typing blind, but having echoed keyboard
characters interspersed with any output a program happens to produce seems
far less helpful than having characters echo in proper relation to where
they are processed.

[toc] | [prev] | [next] | [standalone]

#107099

Am Mittwoch, 22. März 2017 00:12:35 UTC+1 schrieb supe...@casperkitty.com:
> On Tuesday, March 21, 2017 at 4:08:21 PM UTC-5, Jorgen Grahn wrote:
> > Still wouldn't call it "appallingly bad keyboard support" though. I
> > wonder what Bart is referring to.
> 
> MS-DOS, CP/M, and other microcomputer operating systems have separate
> functions to read a keystroke versus reading line-buffered input.  Unix
> can kludge that by switching a terminal to "raw" mode, but the microcomputer
> approach defers the decision about how input will be processed until code
> gets around to processing it.  In MS-DOS, if a program outputs a prompt,
> reads a character without echo, outputs another prompt, and reads a line,
> the first character will not echo to the console, and the line of input will
> echo following the second prompt.  This behavior will occur even if the user
> typed the characters before the program began execution.
> 
> Is there any way to achieve comparable behavior in a Unix console application?

With standard C such things are not possible. When you use Posix
(with terminfo, termcap, curses, tcsetattr, poll, etc.) and Win32
(with ReadConsoleInputW, etc.) then you can achieve comparable
behaviour for Unix (LInux, BSD, OS X, etc.) and Windows.

I have written such driver libraries. They are part of the Seed7
run-time library. This driver libraries are written in C and the
API can accessed from C. The bad message (for probably all in this
group) is: The API is written in a way, that fits to the rest of the
Seed7 run-time library. E.g.: It uses the UTF-32 strings of Seed7.
You can look at the sources of Seed7 for this driver libraries.
The Seed7 run-time library is LGPL so can use it under this license,
but I will not maintain an API, that can just be used outside of the
Seed7 run-time library.

Having said that I can show you how Seed7 achieves your goal.
Your main program should start with this two lines:

  OUT := STD_CONSOLE;
  IN := openEditLine(KEYBOARD, OUT);

This things are defined in libraries you need to include:

  include "keybd.s7i";
  include "console.s7i";
  include "editline.s7i";

After the assignments to IN and OUT you can do:

  write("enter line> ");
  readln(aString);

to read a line. The user can edit the line. There is even a history
of previously entered lines (available with vertical cursor keys).
The line is assigned to aString when ENTER is pressed. Single key
presses are read with:

  aChar := getc(KEYBOARD);

It is also possible to check if a key has been pressed with:

  keypressed(KEYBOARD)

There is also a a function to peek the keyboard with:

  aChar := busy_getc(KEYBOARD);

This function does not wait for a key to be pressed.
If no key has been pressed it returns KEY_NONE.

Reading whole lines and reading single characters can be mixed.
I hope this fulfils your wishes.


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#107101

On 26/03/2017 11:18, mertesthomas@gmail.com wrote:
> Am Mittwoch, 22. März 2017 00:12:35 UTC+1 schrieb supe...@casperkitty.com:

>> Is there any way to achieve comparable behavior in a Unix console application?

> Having said that I can show you how Seed7 achieves your goal.
> Your main program should start with this two lines:
>
>   OUT := STD_CONSOLE;
>   IN := openEditLine(KEYBOARD, OUT);
>
> This things are defined in libraries you need to include:
>
>   include "keybd.s7i";
>   include "console.s7i";
>   include "editline.s7i";
>
> After the assignments to IN and OUT you can do:
>
>   write("enter line> ");
>   readln(aString);
>
> to read a line. The user can edit the line. There is even a history
> of previously entered lines (available with vertical cursor keys).
> The line is assigned to aString when ENTER is pressed. Single key
> presses are read with:
>
>   aChar := getc(KEYBOARD);
>
> It is also possible to check if a key has been pressed with:
>
>   keypressed(KEYBOARD)
>
> There is also a a function to peek the keyboard with:
>
>   aChar := busy_getc(KEYBOARD);
>
> This function does not wait for a key to be pressed.
> If no key has been pressed it returns KEY_NONE.
>
> Reading whole lines and reading single characters can be mixed.
> I hope this fulfils your wishes.

This is nice.

Why can't other APIs be that tidy and that considerate? Why be forced to 
jump through hoops just to read a keypress?

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#107375

Am Sonntag, 26. März 2017 13:35:23 UTC+2 schrieb Bart:
> On 26/03/2017 11:18, mertesthomas wrote:
> > Am Mittwoch, 22. März 2017 00:12:35 UTC+1 schrieb supe...@casperkitty.com:
> 
> >> Is there any way to achieve comparable behavior in a Unix console application?
> 
> > Having said that I can show you how Seed7 achieves your goal.
> > Your main program should start with this two lines:
> >
> >   OUT := STD_CONSOLE;
> >   IN := openEditLine(KEYBOARD, OUT);
> >
> > This things are defined in libraries you need to include:
> >
> >   include "keybd.s7i";
> >   include "console.s7i";
> >   include "editline.s7i";
> >
> > After the assignments to IN and OUT you can do:
> >
> >   write("enter line> ");
> >   readln(aString);
> >
> > to read a line. The user can edit the line. There is even a history
> > of previously entered lines (available with vertical cursor keys).
> > The line is assigned to aString when ENTER is pressed. Single key
> > presses are read with:
> >
> >   aChar := getc(KEYBOARD);
> >
> > It is also possible to check if a key has been pressed with:
> >
> >   keypressed(KEYBOARD)
> >
> > There is also a a function to peek the keyboard with:
> >
> >   aChar := busy_getc(KEYBOARD);
> >
> > This function does not wait for a key to be pressed.
> > If no key has been pressed it returns KEY_NONE.
> >
> > Reading whole lines and reading single characters can be mixed.
> > I hope this fulfils your wishes.
> 
> This is nice.
> 
> Why can't other APIs be that tidy and that considerate? Why be forced to 
> jump through hoops just to read a keypress?

This is not limited to reading a keypress.
Most APIs are rather complex. Ever seen a graphic "Hello world" for
X11 or Win32? I think that the designers of an API usually stop,
when it is possible to do some stuff. The work needed to make
a simple API, not to mention a portable one, is not done.

But the worst thing is: When you complain about the complexity of
an API "experts" will smile at you and tell you that it needs to
be such complex. And how you even can think that it could be
simpler. :-)


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web