Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #101543 > unrolled thread
| Started by | "Fernando D. Bozzo" <fdbozzo@gmail.com> |
|---|---|
| First post | 2017-01-12 11:48 -0800 |
| Last post | 2017-01-13 23:46 +0800 |
| Articles | 20 on this page of 190 — 24 participants |
Back to article view | Back to comp.lang.c
Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 11:48 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 11:58 -0800
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 01:35 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 17:43 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 02:19 +0000
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 19:26 -0800
Re: Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-13 00:28 -0800
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 10:56 +0000
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-16 12:23 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 12:49 +0100
Re: Naming convention for structs and types Thiago Adams <thiago.adams@gmail.com> - 2017-01-13 05:03 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 16:00 +0100
Re: Naming convention for structs and types Thiago Adams <thiago.adams@gmail.com> - 2017-01-13 18:28 -0800
Re: Naming convention for structs and types supercat@casperkitty.com - 2017-01-13 18:58 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 14:07 +0100
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-14 14:31 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-13 09:20 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 18:47 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-13 10:02 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 21:42 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-13 12:55 -0800
Re: Naming convention for structs and types supercat@casperkitty.com - 2017-01-13 13:09 -0800
Re: Naming convention for structs and types Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 21:01 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-12 17:48 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 19:35 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-12 19:45 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-12 19:51 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-12 21:12 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 12:53 +0100
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-13 08:59 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 18:48 +0100
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-13 18:03 -0800
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:05 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-13 19:30 +1300
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 13:00 +0000
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 10:43 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 18:52 +0000
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 12:56 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 10:54 +1300
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-13 22:00 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 11:18 +1300
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 00:59 +0000
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 17:12 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 14:47 +1300
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 01:36 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 11:26 +0000
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 14:11 +0000
Re: Naming convention for structs and types Parity Error <kgf@quiscurat.net> - 2017-01-15 08:33 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-15 02:52 -0800
Re: Naming convention for structs and types Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-15 14:48 +0100
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:07 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 14:40 +1300
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 11:28 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 11:48 +0000
Re: Naming convention for structs and types Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-14 13:17 +0100
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 14:21 +0100
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 13:27 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 14:00 +0000
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 14:11 +0000
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 14:12 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 16:18 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 16:31 +0000
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 18:50 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 19:48 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-15 10:15 +1300
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 20:12 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 23:31 +0100
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 10:28 -0800
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 18:52 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-14 14:49 -0800
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-14 14:41 -0800
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-14 23:03 +0000
Re: Naming convention for structs and types Parity Error <kgf@quiscurat.net> - 2017-01-15 08:41 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-16 20:01 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 00:19 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 00:29 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 09:12 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 11:59 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 13:16 +0000
OT: Bash tab completion (was: Naming convention for structs and types) Andreas Perstinger <andipersti@gmail.com> - 2017-01-17 13:27 +0000
Re: OT: Bash tab completion BartC <bc@freeuk.com> - 2017-01-17 13:59 +0000
Re: OT: Bash tab completion David Brown <david.brown@hesbynett.no> - 2017-01-17 15:49 +0100
Re: OT: Bash tab completion fir <profesor.fir@gmail.com> - 2017-01-17 07:06 -0800
Re: OT: Bash tab completion fir <profesor.fir@gmail.com> - 2017-01-17 07:43 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 15:18 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 19:26 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 21:53 +0100
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-17 20:56 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 21:38 +0000
Re: Naming convention for structs and types fir <profesor.fir@gmail.com> - 2017-01-17 14:22 -0800
Re: Naming convention for structs and types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-17 23:43 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 00:33 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 11:03 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 12:15 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 13:59 +0100
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 15:45 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 17:28 +0100
Re: Naming convention for structs and types supercat@casperkitty.com - 2017-01-18 09:30 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 23:18 +1300
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 21:22 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 12:47 +0100
Re: Naming convention for structs and types fir <profesor.fir@gmail.com> - 2017-01-18 08:11 -0800
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 17:17 +0000
Re: Naming convention for structs and types fir <profesor.fir@gmail.com> - 2017-01-18 09:47 -0800
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-18 21:20 +0000
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 22:26 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-19 00:31 +0100
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-18 15:41 -0800
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-18 23:58 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-17 11:49 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 21:56 +0100
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-17 13:18 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 12:50 +0100
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 07:51 +1300
Re: Naming convention for structs and types BartC <bc@freeuk.com> - 2017-01-17 19:50 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 21:59 +0100
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 17:51 +1300
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:15 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-19 07:52 +1300
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 12:09 +0000
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-14 13:26 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-15 08:10 +1300
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 12:28 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-15 10:17 +1300
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 15:12 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 12:31 +1300
Re: Naming convention for structs and types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 16:03 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-13 15:57 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-14 13:29 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-14 10:45 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-16 12:19 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 15:22 -0800
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-16 16:35 -0800
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-17 17:02 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-17 20:57 +1300
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-17 08:47 +0000
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 08:03 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-17 07:04 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 08:01 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-17 11:47 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-17 22:16 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-17 15:44 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 17:59 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-18 04:42 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-19 07:57 +1300
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-18 11:22 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 13:36 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-18 05:07 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 16:09 +0100
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-18 07:36 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-18 17:32 +0100
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-18 17:55 +1300
Re: Naming convention for structs and types "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-19 22:28 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-20 08:36 +0000
Re: Naming convention for structs and types "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-20 04:27 -0800
Re: Naming convention for structs and types luser droog <luser.droog@gmail.com> - 2017-01-12 12:01 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 20:11 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 12:50 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 21:02 +0000
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 13:26 -0800
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 21:35 +0000
Re: Naming convention for structs and types luser droog <luser.droog@gmail.com> - 2017-01-12 16:37 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 12:57 +0100
Re: Naming convention for structs and types Gareth Owen <gwowen@gmail.com> - 2017-01-13 16:38 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-13 17:52 +0100
Re: Naming convention for structs and types Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 20:07 +0000
Re: Naming convention for structs and types Thiago Adams <thiago.adams@gmail.com> - 2017-01-12 12:45 -0800
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 13:01 -0800
Re: Naming convention for structs and types jadill33@gmail.com - 2017-01-12 13:57 -0800
Re: Naming convention for structs and types John Bode <jfbode1029@gmail.com> - 2017-01-12 13:59 -0800
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-12 15:08 -0800
Re: Naming convention for structs and types Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 10:33 -0800
Re: Naming convention for structs and types Keith Thompson <kst-u@mib.org> - 2017-01-14 15:20 -0800
Re: Naming convention for structs and types Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 21:31 -0800
Re: Naming convention for structs and types Ian Collins <ian-news@hotmail.com> - 2017-01-13 19:43 +1300
Re: Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-13 01:00 -0800
Re: Naming convention for structs and types James Kuyper <jameskuyper@verizon.net> - 2017-01-13 13:03 -0500
Re: Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-13 16:02 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 13:36 +0100
Re: Naming convention for structs and types "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-14 05:22 -0800
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-14 17:27 +0100
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-18 21:05 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-19 09:48 +0100
Re: Naming convention for structs and types James Kuyper <jameskuyper@verizon.net> - 2017-01-19 13:31 -0500
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-19 21:18 +0100
Re: Naming convention for structs and types raltbos@xs4all.nl (Richard Bos) - 2017-01-22 17:10 +0000
Re: Naming convention for structs and types David Brown <david.brown@hesbynett.no> - 2017-01-22 18:27 +0100
Re: Naming convention for structs and types James Kuyper <jameskuyper@verizon.net> - 2017-01-13 12:49 -0500
Re: Naming convention for structs and types supercat@casperkitty.com - 2017-01-13 09:55 -0800
Re: Naming convention for structs and types "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-01-13 23:46 +0800
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-17 13:59 +0000 |
| Subject | Re: OT: Bash tab completion |
| Message-ID | <o5l7te$fuj$1@dont-email.me> |
| In reply to | #102038 |
On 17/01/2017 13:27, Andreas Perstinger wrote: > On 2017-01-17, BartC <bc@freeuk.com> wrote: >> I get a list of possibilities, and it repeats what I had before. How do >> I get it to auto-complete that blasted ".c"?! I can't. > > Sure, you can. :-) > >> Now let's try that again but on Windows; I type 'gcc hello' up to the >> 'o' again: >> >>> gcc hello >> >> Now I press tab: >> >>> gcc hello.ali >> >> And I magically get the first extension! Not quite the one I want, which >> is the problem with tabbing, but it's now doing what it says on the box. > > Since you are using Ubuntu I guess your interactive shell is bash. So just > type > > $ bind '"\t": menu-complete' > > and you should get the behaviour you are used to on Windows. And I was right! I did have to twoggle the zwiggle-stick on the thingamijig! (However, this setting is not persistent as every time I start a new terminal window, I get the same default behaviour. Some more twoggling needed I guess. But the problem will still be there if using someone else's machine, or a shared one, and they might not want their settings twoggled.) > For more information: "man bash" (section READLINE). Even with the hint I couldn't find the right bit. This thing is complicated (5500 lines or 100 pages of explanation). A shell is primarily so you can type: command parameter-list and it can barely get that right. (Try typing 'man *' and it goes bonkers.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-17 15:49 +0100 |
| Subject | Re: OT: Bash tab completion |
| Message-ID | <o5laqi$q9p$1@dont-email.me> |
| In reply to | #102041 |
On 17/01/17 14:59, BartC wrote: > On 17/01/2017 13:27, Andreas Perstinger wrote: >> On 2017-01-17, BartC <bc@freeuk.com> wrote: >>> I get a list of possibilities, and it repeats what I had before. How do >>> I get it to auto-complete that blasted ".c"?! I can't. >> >> Sure, you can. :-) >> >>> Now let's try that again but on Windows; I type 'gcc hello' up to the >>> 'o' again: >>> >>>> gcc hello >>> >>> Now I press tab: >>> >>>> gcc hello.ali >>> >>> And I magically get the first extension! Not quite the one I want, which >>> is the problem with tabbing, but it's now doing what it says on the box. >> >> Since you are using Ubuntu I guess your interactive shell is bash. So >> just >> type >> >> $ bind '"\t": menu-complete' >> >> and you should get the behaviour you are used to on Windows. > > And I was right! I did have to twoggle the zwiggle-stick on the > thingamijig! > > (However, this setting is not persistent as every time I start a new > terminal window, I get the same default behaviour. Some more twoggling > needed I guess. But the problem will still be there if using someone > else's machine, or a shared one, and they might not want their settings > twoggled.) As always, there is a simple solution that is a mere google away. But you'd rather complain. You can but the command in your own ~/.bashrc file to make it apply to all new bash terminals, or in /etc/bashrc to make it apply to /everyone's/ new bash terminals on the computer. Oddly enough, there is no way to change the setting on /your/ machine to make it affect someone else's machine, so I suppose that's still a "problem" in your book. > >> For more information: "man bash" (section READLINE). > > Even with the hint I couldn't find the right bit. This thing is > complicated (5500 lines or 100 pages of explanation). A shell is > primarily so you can type: > > command parameter-list > > and it can barely get that right. (Try typing 'man *' and it goes bonkers.) > You could also try googling "How do I make linux tab completion work like windows?" You'll find that someone else has already asked in an appropriate place rather than a C newsgroup, and got an answer.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-01-17 07:06 -0800 |
| Subject | Re: OT: Bash tab completion |
| Message-ID | <4b8380dc-b183-4107-822b-ade121d1e5a3@googlegroups.com> |
| In reply to | #102041 |
W dniu wtorek, 17 stycznia 2017 14:59:50 UTC+1 użytkownik Bart napisał: i personally understand your point as obvious (it is obvious for me that languages should be build this way that minimal external reference should be needed to work in them.. sadly large parts of todays world gone different way.. i recently mentioned tower of babel effect (which is programing reality today) Torre de Babel La Torre de Babel ye una construcción de tipu zigurat que ye mentada na Biblia. Sigún se narra nel capítulu 11 del Xénesis, los homes pretendíen, cola construcción d'esta torre, algamar el cielu. probably much more can be said on that but i got no special idea.. afair they never build this becouse there was to many languages.. whan you got many languages to be general specialist mean you want to spend times of more time to learn it, whan you got one not only you but whole society can focus on tis and build much more.. maybe it weakaning factor works just in linear you got 1* 100% or 2*50% and so on... now its all shattered and coding culture is broken (i could try focus on one main line alone, but from some (psychological?) reasons it is harder (to that observable extent it dont quite work to me - it worked better when i got old machine and thus i had to focus on one tehnology ) - besides that whole culture is lost (and if i theoreticcaly can think of mending myself, mending culture is theoretically harder ;C ) know what im sayin fir
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-01-17 07:43 -0800 |
| Subject | Re: OT: Bash tab completion |
| Message-ID | <3f19a927-180c-4165-bffa-8e43df05b814@googlegroups.com> |
| In reply to | #102049 |
W dniu wtorek, 17 stycznia 2017 16:07:04 UTC+1 użytkownik fir napisał: > Torre de Babel > > La Torre de Babel ye una construcción de tipu zigurat que ye mentada na Biblia. Sigún se narra nel capítulu 11 del Xénesis, los homes pretendíen, cola construcción d'esta torre, cel cielu. > ps this is asturian (feels like better than spanish) i know polish, in english i can read and write with errors, read weakly french (but unable to write) i would also like to learn spanish (or asturian, so on) - spanish is really fine language probably is the simplest language i know (i can read it weakly not knowing it).. as a child always thinked that english is most elegant (as it is unusually simple not like in polish where words change under declension, are long and weird ) but spanish is also real fine.. i ilike all three immensely, may say, coz french also looks very fine, There is some freshness in all three (i would probably learn some fifth one (next one after the previous always easier to learn) but got no idea, i had ambition to learn japaneese but thats seem much harder story - no easy entry point)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-17 15:18 +0100 |
| Message-ID | <o5l90q$k09$1@dont-email.me> |
| In reply to | #102033 |
On 17/01/17 12:59, BartC wrote: > On 17/01/2017 08:12, David Brown wrote: >> On 17/01/17 01:29, BartC wrote: > >> The actual C compiler is "cc1", and the C++ compiler is "cc1plus". Not >> that it matters to anyone - you should use "gcc" (or g++ if you prefer) >> as the driver. > > And the actual linker is ld. Which if you try and run it separately, > doesn't work because it's driven in a very complicated manner. It works fine if you know how to use it. I usually use gcc to run the linker, but sometimes I run ld directly. > (When I > once tried to intercept the options that gcc was feeding it, it turns > out, iirc, it was running programs to create a script to feed to ld. gcc > can't do anything simply when there is a more complicated alternative!) That sounds like a description of a certain Usenet poster... > > Using one program for compiling .c, one for .cpp, and another for > linking seems a lot simpler to me. Combining them into one script is > child's play for anyone used to C code. With gcc, there /is/ one program for compiling C (cc1), one for compiling C++ (cc1plus), one for linking (ld). There are a few others too - one for C pre-processing (cpp), one for compiling link-time optimised files (lto1), one for assembling (as), and a variety of utility programs that are usually associated with gcc. (Note that "ld" and "as" are not actually part of the gcc suite - they are from the binutils project.) And there is a driver program that combines them, gcc, along with a second convenience driver program g++ that saves you specifying the C++ library. So gcc gives you exactly what you are asking for here. > >> I have not had to pass a header to the compiler either, but it is a >> feature that some people might use. I certainly pass things other than >> .c files to it. > > This is because it combines cc1, cc1plus and ld (and other programs that > are also called such as the assembler). > > If the programs were separate, the range of file extensions each would > need cope with would be far smaller, and a natural default extension far > more viable. And how would that help me? It's easy to type "gcc -c hello.c" to compile a C file and "gcc -c hello.cpp" to compile a C++ file. In what world is that so much more difficult than typing "cc1 -c hello" and "cc1plus hello" would be? You are not just making a mountain out of a molehill here - you first made the molehill yourself. > >>> Tab completion doesn't seem to work with Ubuntu. It works as far as the >>> ".", but typing Tab here just shows a list of possibilities; it doesn't >>> complete the extension. >> >> Trust me, it works for everyone else's Linux system since the dawn of >> time. But you excel at failing to do what others find easy. > > I excel at finding bugs in other people's programs, especially > compilers. And I excel at finding troublesome issues in user interfaces. "Troubleshooting issues in user interfaces" is a useful skill. Getting all worked up because one program does not work in exactly the way another program works is not troubleshooting or bug-finding. > (You presumably excel at brushing them under the carpet!) > > With this one, I start here with 7 hello.* files including hello.c: > > $ > > Now I type this, up to the 'o': > > $ gcc hello > > Now I press Tab, it gives me: > > $ gcc hello. > > OK, that was useful; pressing Tab saved me one keystroke! But there is > no actual "hello." file. I press Tab again: > > $ gcc hello. > > No change. I press Tab one more time: > > hello.asm64 hello.cc hello.m hello.q > hello.c hello.exe hello.mx > $ gcc hello. > > I get a list of possibilities, and it repeats what I had before. How do > I get it to auto-complete that blasted ".c"?! I can't. Just type the "C" key! And buy yourself a copy of "Linux for Dummies", or perhaps "Bash for Dummies". Or perhaps just by yourself a dummy, so that we don't have to listen to more crying about things you don't understand and are too stubborn to learn. > > This is, of course, all /my/ fault. Because I haven't twoggled the > zwiggle-stick on the thingamijig. <palm to forehead!> It is all /your/ fault for your total and complete inability to understand that things might be slightly different for different programs or different systems, and your total inability to understand how to use a computer. The standard Linux shell requires you to press the "C" key for this auto-completion, rather than stupidly bashing at the the tab key repeatedly until the required filename rolls round. It is fine to /prefer/ the windows style auto-completion to the *nix style. It is fine to say that sometimes one is more convenient than the other. But it is not fine to fail to understand something that simple! > > Now let's try that again but on Windows; I type 'gcc hello' up to the > 'o' again: > >> gcc hello > > Now I press tab: > >> gcc hello.ali > > And I magically get the first extension! Not quite the one I want, which > is the problem with tabbing, but it's now doing what it says on the box. > >> I suspect in this case it is because you expect *nix style completion to >> work exactly like Windows-style completion. It is a little different. > > Oh, like, it doesn't actually auto-complete! So what /does/ it do? > >>> Even if it did work, you'd probably have to cycle through all the >>> possibilities first. If I pressed Tab after typing 'gcc hello' in my >>> main C directory, it might work through hello.ali, .asm, .asm64, .b, >>> .bas, .bx, .cl, .cpp, .cx, .dll, .exe, .ftn, .h, .i, .lsp, .m, .map, >>> .mx, .o, .obj, .pc, .pcs, .png, .pro, .q, .s, and finally .c! (Actually >>> it appears to do them in alphabetical order, but it would still be the >>> 7th option; it would be quicker to just type .c.) >>> >>> Some apps do work properly: 'unzip fred' for example will unzip >>> fred.zip. And the world doesn't seem to have ended yet. >> >> That is not "working properly" - that is simply "using a default >> extension if non is given", which is a choice that an application >> developer can make. > > Since 99.99% of the time, the extension of the file /will/ be .zip, for > what perverse, sadistic reason would the developer INSIST that the > extension is always typed out in full? You've found the master plan! Some 30+ years ago the early Unix world found a prophecy that showed the coming of the /Bart/, and could see that his greatness would cause disruption for the Unix world. The realised that the only way to stop this would be a concerted effort to spoil Bart's future by making a shell auto-completion feature that differed from the non-existent Windows feature, and by forcing people to type file extensions. They ganged up with Richard Stallman to make sure that programs and file organisations that would cunningly be perfectly usable by everyone except the Bart. And now you have seen through this global decades-long conspiracy designed specifically to plague you. I guess I'll just send off some emails to Linus Torvalds and RMS to inform them that Linux is dead, as is GNU and gcc, and we will all now switch to Windows to get the one true auto-completion feature, and Bart's own C compiler because it compiles quickly - and what other features could anyone want from a compiler? > >> In this case, you should understand that in *nix, a file's type is >> determined by its contents - /not/ by its extension as it is in Windows. > > We should be grateful then that file extensions such as .c, .cpp and .o > exist at all. But then even Unix realised if that if 'hello' is a C > source file, then you're going to be stuck for a name for the asm file, > the pp file, the map file, the listing file , the object file and the > executable as they can't all be called 'hello'. (Or can they? Unix seems > to excel in allowing stuff like this.) They are different files, and need different names. But the extensions like ".o" are not essential - you can give your object files any name you want. In *nix, a file extension is just a bit of the file name (and there can be many dots if you want) that is convenient to users. Nothing more, nothing less. A file might be called "source.tar.bz2" to tell /people/ that it is a bzip2'd tarball - the /computer/ and its software don't care. > >> In *nix, file extensions are just part of a file's name, > > Odd then that auto-complete would stop at "." in that case; what's > special about "."? It is the last character in common amongst all the files. > >>> Such a brilliantly simple idea, but most people seem to be intent on >>> making poor programmers work a little bit harder! >>> >> >> Yes, typing ".c" is such a hardship! > > Yes I know. You're always so optimistic; nothing is a hardship; nothing > is too much work; nothing is too complicated; or too slow; or too full > or problems. Even if you admit that something could be better, you just > shrug and get on with it. If it is a problem that I can fix, I might try to fix it. If it is a problem that I could reasonably and realistically influence by reporting back to the developers, standards committee, or whatever, then I might well report it back. If I know that it is not going to change no matter what I do, or that I know the reasoning behind, or that I know is not a problem for other people - then yes, I just shrug and get on with it. It is a good deal more sensible than ranting about it in a newsgroup! And I truly, honestly, believe that typing ".c" is not a hardship. It is not a problem - I am quite happy with it. To the extent that I care at all, which is a /very/ small extent, I prefer it to alternatives such as different compiler names for different tools. When I am working on anything that is not completely trivial, my compilation command is "make" without the need to specify any files at all, extensions or not. And even "make" is usually abbreviated to control-B. > > There are too types of people: those who shrug; and those who don't > shrug and try and make things a bit different. There seems to be a third type - those who invent problems so that they can complain endlessly about them. > > I mean, who was the guy who invented tab-completion? When he touted his > or her idea around, I bet everyone just shrugged their shoulders and > said, what's the hardship in having to type the rest of a filename > yourself! It's easier than digging a hole after all. > Have you ever actually /used/ tab completion on Windows? And actually /used/ it on Linux? I use the command line a great deal, on both systems, and while the Windows method is occasionally faster, the *nix method is more efficient for most of /my/ usage. This is partly because it covers a great deal more than just filenames, but I find the way it works is nicer. With Windows auto-completion, I am often rolling around and around to get the file I want, or having to delete large swaths of unwanted characters in the suggested name in order to limit the range.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-17 19:26 +0000 |
| Message-ID | <o5lr2b$req$1@dont-email.me> |
| In reply to | #102043 |
On 17/01/2017 14:18, David Brown wrote: > On 17/01/17 12:59, BartC wrote: > The standard Linux shell requires you to press > the "C" key for this auto-completion I don't understand. You mean "C" as a special command for tab-completion, or "c" to manually finish off the name? But never mind... > the one > true auto-completion feature, Well, the Windows feature works pretty much as one would expect. Anything even slightly more sophisticated than a command line, you'd be looking at a list of possibilities anyway and you don't need to type the full name of it to action it. But given that sometimes you have to use a command line, at least make it simple, and make it user-friendly and make it work exactly like anyone might expect. > and Bart's own C compiler because it > compiles quickly - and what other features could anyone want from a > compiler? Not just speed, it should be effortless. I know enough now to realise that compiling a single module should essentially complete in 0 seconds or near enough zero (less time than it takes you to press one key). Once you have the speed, then a range of interesting things become possible. > In *nix, a file extension is just a bit of the file name (and > there can be many dots if you want) that is convenient to users. > Nothing more, nothing less. A file might be called "source.tar.bz2" to > tell /people/ that it is a bzip2'd tarball - the /computer/ and its > software don't care. Really? If I copy hello.c (a C source file) to hello.bz2, then the file manager highlights it just like an actual .bz2 file (with a folder icon with an embedded 'bz2'). And it gets tied up in knows trying to open it. Which is odd because if I take an actual .bz2 file, and copy it to a file with no extension, then it deals with it properly (so it must be looking at the signature). (See, I told you I have a knack for sniffing out UI problems.) Anyway Unix can't really do without file extensions, much as it would like to. They are needed both for users and for programs. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-17 21:53 +0100 |
| Message-ID | <o5m05b$gpe$1@dont-email.me> |
| In reply to | #102065 |
On 17/01/17 20:26, BartC wrote: > On 17/01/2017 14:18, David Brown wrote: >> On 17/01/17 12:59, BartC wrote: > >> The standard Linux shell requires you to press >> the "C" key for this auto-completion > > I don't understand. You mean "C" as a special command for > tab-completion, or "c" to manually finish off the name? But never mind... > The "C" key to finish off the name, obviously. >> the one >> true auto-completion feature, > > Well, the Windows feature works pretty much as one would expect. No, it works the way /you/ expect because it is the way /you/ are familiar with. How can you not understand this? It's as though you were arguing with a Chinese man that English is so much easier than Mandarin because it is more intuitive. > Anything even slightly more sophisticated than a command line, you'd be > looking at a list of possibilities anyway and you don't need to type the > full name of it to action it. Try the Unix way and the Windows way on large directories, and see what it is actually like in practice. I am not suggesting that you should /prefer/ the Linux way - merely that you understand that they are different, that some people prefer one way to the other way, and that it is as much a matter of familiarity as anything else. > > But given that sometimes you have to use a command line, at least make > it simple, and make it user-friendly and make it work exactly like > anyone might expect. The bash command line works pretty much exactly like bash users expect. Note that bash is massively configurable, and can have completion in the Windows way. Still, the default settings for distributions - including those aimed at newbies or Windows refugees - use the standard bash completion. They do so because people who are familiar with both are happy that the bash way is usually faster, easier, and more helpful. But bash also supports the Windows way for people who are so used to that system that they are happier with that method. > >> and Bart's own C compiler because it >> compiles quickly - and what other features could anyone want from a >> compiler? > > Not just speed, it should be effortless. I know enough now to realise > that compiling a single module should essentially complete in 0 seconds > or near enough zero (less time than it takes you to press one key). > > Once you have the speed, then a range of interesting things become > possible. > >> In *nix, a file extension is just a bit of the file name (and >> there can be many dots if you want) that is convenient to users. >> Nothing more, nothing less. A file might be called "source.tar.bz2" to >> tell /people/ that it is a bzip2'd tarball - the /computer/ and its >> software don't care. > > Really? If I copy hello.c (a C source file) to hello.bz2, then the file > manager highlights it just like an actual .bz2 file (with a folder icon > with an embedded 'bz2'). And it gets tied up in knows trying to open it. You are talking about a file manager - a program. Not the operating system. Certainly some programs take shortcuts in identifying file types, such as assuming that file extensions match - just as people do. But the underlying system does not care, and a great many (but not all) programs designed for the *nix world will handle files correctly regardless of the extension, if any. > > Which is odd because if I take an actual .bz2 file, and copy it to a > file with no extension, then it deals with it properly (so it must be > looking at the signature). It would seem that when there is no file extension, the file manager you are using (of which there are many) inspects the contents. Inspecting the contents takes more time than reading the file extension, which is probably why it picks this compromise. > > (See, I told you I have a knack for sniffing out UI problems.) I don't see a problem - I see a reasonable balance for identifying files correctly when the user uses sensible names. I am sure if you were interested you could find an alternative file manager that always inspected file contents regardless of the name. > > Anyway Unix can't really do without file extensions, much as it would > like to. They are needed both for users and for programs. > They are extremely useful for users, and thus programs may rely on the same conventions for convenience and efficiency. But they certainly do not have the same place in the *nix world as they do in Windows, which cannot work without them.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-01-17 20:56 +0000 |
| Message-ID | <87fukh2ynd.fsf@gmail.com> |
| In reply to | #102073 |
David Brown <david.brown@hesbynett.no> writes: > How can you not understand this? Have you not been paying attention? How can you still be surprised at Bart's inability to grasp anything remotely complex or out of his narrow experience?
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-17 21:38 +0000 |
| Message-ID | <o5m2qk$r0n$1@dont-email.me> |
| In reply to | #102075 |
On 17/01/2017 20:56, Gareth Owen wrote: > David Brown <david.brown@hesbynett.no> writes: > >> How can you not understand this? > > Have you not been paying attention? How can you still be surprised at > Bart's inability to grasp anything remotely complex or out of his narrow > experience? > I wonder if there is anyone whose job it is to keep tabs on the complexity of such UI systems as have been discussed? Or are these things just allowed to grow out of hand until they become completely impossible? How many man-pages does bash have to accumulate before it would considered even by Unix aficionados to be over the top? With attitudes such as those that have been demonstrated here, I wouldn't be at all surprised if there were no curbs at all. Anyone who dares to question anything or, god forbid, strives to simplify anything, will be laughed at as an ignorant bozo who can't be bothered or is incapable of learning The Manual. (Asimov's long short story /Profession/ has an interesting take on this, in showing the benefits of taking a wider perspective on these matters, rather than having an unshakable faith in a myriad of complex details.)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-01-17 14:22 -0800 |
| Message-ID | <a10a5d1f-6b41-4728-b66a-f55dcfa03628@googlegroups.com> |
| In reply to | #102081 |
W dniu wtorek, 17 stycznia 2017 22:39:10 UTC+1 użytkownik Bart napisał: > On 17/01/2017 20:56, Gareth Owen wrote: > > David Brown <david.brown@hesbynett.no> writes: > > > >> How can you not understand this? > > > > Have you not been paying attention? How can you still be surprised at > > Bart's inability to grasp anything remotely complex or out of his narrow > > experience? > > > > I wonder if there is anyone whose job it is to keep tabs on the > complexity of such UI systems as have been discussed? Or are these > things just allowed to grow out of hand until they become completely > impossible? > > How many man-pages does bash have to accumulate before it would > considered even by Unix aficionados to be over the top? > > With attitudes such as those that have been demonstrated here, I > wouldn't be at all surprised if there were no curbs at all. Anyone who > dares to question anything or, god forbid, strives to simplify anything, > will be laughed at as an ignorant bozo who can't be bothered or is > incapable of learning The Manual. > > (Asimov's long short story /Profession/ has an interesting take on this, > in showing the benefits of taking a wider perspective on these matters, > rather than having an unshakable faith in a myriad of complex details.) the more the system is big the more you need to learn it untill you can use it; this is even somewhat independant to babel problem, though i think pure growing of the system is not such bad as the tehnologies scattering (babel problem) or just errors made in design
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-17 23:43 +0000 |
| Message-ID | <874m0xgslm.fsf@bsb.me.uk> |
| In reply to | #102081 |
BartC <bc@freeuk.com> writes: <snip> > I wonder if there is anyone whose job it is to keep tabs on the > complexity of such UI systems as have been discussed? Or are these > things just allowed to grow out of hand until they become completely > impossible? > > How many man-pages does bash have to accumulate before it would > considered even by Unix aficionados to be over the top? > > With attitudes such as those that have been demonstrated here, I > wouldn't be at all surprised if there were no curbs at all. I don't think you've grasped the fundamental philosophical difference between systems like Windows and systems like GNU/Linux -- the difference between the cathedral and the bazaar, as outlined in the eponymous book. Linux has dozens of shells, numerous desktop systems, loads of window managers, not to mention boot loaders and startup-systems; and all of them have thousands of configurations options and settings. Different "distributions" package up diverse subsets of programs, and even a single distributions can come in multiple flavours. It's chaos. I happen to like it. Some people are happy in uncontrolled, chaotic environments. The cathedral solution to a problem like "too many man pages" is to have curbs (as you put it). In the bazaar, if someone cares enough they fix it -- possibly by writing a simplified manual and offering that as an option. The long one will remain happily un-curbed. If no one has time or cares enough, nothing happens and people muddle along. It's not that that chaos does not cause problems -- it does, lots of then -- it's that there is nothing you can do about other than sit back or step up -- you can't petition the bishop to issue an edict. You will find endless things to moan about in the chaos, but the only answers that make any philosophical sense are "don't use it", "configure it" or "write a better version". Given all you've posted on these things, I can't help wondering why on earth you are using a Linux flavour at all. Nothing about it seems to suit your preferences or coincide with your intuition, and I don't get the feeling that you are forced to use it for work. The simplest solution would be just to leave it alone. The objective of the bazaar is not to dominate the skyline and win converts, but simply to provide a home for diverse solutions where you might find something of value. I don't think you have found anything of value there. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-18 00:33 +0000 |
| Message-ID | <o5md1m$q0$1@dont-email.me> |
| In reply to | #102089 |
On 17/01/2017 23:43, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: [Unix vs. Windows - sort of] >> With attitudes such as those that have been demonstrated here, I >> wouldn't be at all surprised if there were no curbs at all. > > I don't think you've grasped the fundamental philosophical difference > between systems like Windows and systems like GNU/Linux -- the > difference between the cathedral and the bazaar, as outlined in the > eponymous book. > > Linux has dozens of shells, numerous desktop systems, loads of window > managers, not to mention boot loaders and startup-systems; and all of > them have thousands of configurations options and settings. Different > "distributions" package up diverse subsets of programs, and even a > single distributions can come in multiple flavours. It's chaos. I > happen to like it. Some people are happy in uncontrolled, chaotic > environments. > > The cathedral solution to a problem like "too many man pages" is to have > curbs (as you put it). In the bazaar, if someone cares enough they fix > it -- possibly by writing a simplified manual and offering that as an > option. The long one will remain happily un-curbed. If no one has time > or cares enough, nothing happens and people muddle along. > > It's not that that chaos does not cause problems -- it does, lots of > then -- it's that there is nothing you can do about other than sit back > or step up -- you can't petition the bishop to issue an edict. You will > find endless things to moan about in the chaos, but the only answers > that make any philosophical sense are "don't use it", "configure it" or > "write a better version". It's a refreshing change for someone to acknowledge that Unix might not be perfect after all! > Given all you've posted on these things, I can't help wondering why on > earth you are using a Linux flavour at all. It's a challenge. Also I wanted to do something with my Raspberry Pi (one of the early slow ones), and that uses Linux. I didn't expect to have anything much to do with Linux once I'd ported my main tools across, because then I'd be working inside my tools and removed from most of the OS's idiosyncrasies. But that hasn't happened yet. (A couple of months back I did have crude, part-working versions of my (console mode) IDE and editor working on Linux including the RPi. And that used binary byte-code that worked, unchanged, on either OS. I got quite a kick from that. But then I started on something different.) Now, on that Rpi machine (never mind that newer ones are apparently faster), I reckoned that worked at about 1/8 the speed of my desktop PC. Yet I was measuring the gcc C compiler at 100 to 500 lines per second, which is very poor. And I haven't had much luck sourcing a faster C compiler for ARM (more DIY involved in hacking things around). So I'm currently interested in fast C compilers to see what I can do, and what is possible. These little UI problems are a nuisance, but I was more interested in the odd attitudes to issues that may be trivial matters but that could also have trivial solutions. People seem to want to defend these things to the death (eg. case sensitivity of the OS, the chaos that typing 'man *' may cause, the disseminated file system, lack of standards for character/non-blocking keyboard i/o and basic console i/o, the fantastically elaborate gcc suite of compilers, complete dependence on 'make' and the non-portable 'configure'). Almost as though they take pride in knowing all this arcane stuff. I prefer Windows but if it merits it I will criticise that too. > Nothing about it seems to > suit your preferences or coincide with your intuition, and I don't get > the feeling that you are forced to use it for work. There were also scare stories a few years ago that it would be impossible to develop programs for new Windows OSes using your own tools (making it as hard as doing stuff for iPad/iPhone or Android). I didn't want to quit coding just yet, and Linux seemed to be the only option (as I can't and don't want to do hardware any more). > The simplest > solution would be just to leave it alone. The objective of the bazaar > is not to dominate the skyline and win converts, but simply to provide a > home for diverse solutions where you might find something of value. I > don't think you have found anything of value there. I don't agree. I think the OS is usable once a set of problems have been solved. But I haven't been impressed with what I'm discovering on the way. In the meantime, the need for portability, to need to work on either OS, means the quality of my coding has improved. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-18 11:03 +0100 |
| Message-ID | <o5nedq$ce4$1@dont-email.me> |
| In reply to | #102091 |
On 18/01/17 01:33, BartC wrote: > On 17/01/2017 23:43, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > > [Unix vs. Windows - sort of] >> >> It's not that that chaos does not cause problems -- it does, lots of >> then -- it's that there is nothing you can do about other than sit back >> or step up -- you can't petition the bishop to issue an edict. You will >> find endless things to moan about in the chaos, but the only answers >> that make any philosophical sense are "don't use it", "configure it" or >> "write a better version". > > It's a refreshing change for someone to acknowledge that Unix might not > be perfect after all! Given what I and others have posted here, that statement is borderline insulting. Certainly I have taken pains to describe differences between "the Windows Way" and "the Unix Way" as just that - /differences/. I have made it clear that I often /prefer/ the *nix way, but that sometimes or for some purposes I think the Windows way is better. I have often given reasons for why a particular facet of *nix (or gcc, since you like to view them as intertwined) is big, complex or slow - that is far from saying that it is "perfect" that it is big, slow or complex. It is merely saying that it is understandable, and not a problem. > >> Given all you've posted on these things, I can't help wondering why on >> earth you are using a Linux flavour at all. Actually, it is more of a wonder that you are using C, which you are determined to misunderstand and hate. > > People seem to want to defend these things to the death (eg. case > sensitivity of the OS, That is a good thing, IMHO. Your preferences may vary - that's what preferences do. the chaos that typing 'man *' may cause, the I can think of plenty of ways to cause chaos on a computer, Linux or Windows. Asking the machine to display all the documentation it has for all the software installed is going to be a demanding task. Fortunately, it's not a problem because it is a pointless thing to do. > disseminated file system, The filessytem organisation in Linux is not perfect, but it's not bad. Clearly it can be confusing when you are not familiar with it, and are unable to google for "overview of the Linux filesystem organisation". The Windows organisation is much, much worse. It is full of hidden directories, fake directories that look different depending on which user is accessing them or which program, huge directories within the c:\windows hierarchy whose very size slows down the system, "temp" directories that swell up with tens of thousands of files that are not cleared up automatically and are very hard to clear manually, directory names of ridiculous lengths full of "unfriendly" characters like spaces and brackets, on an OS that has a 260 character limit on the total path length. > lack of standards for character For most low-level aspects, *nix does not care about what character set you use. For user interaction, you usually have good UTF-8 support, character entry, fonts, etc., right out of the box. > /non-blocking > keyboard i/o and basic console i/o, the fantastically elaborate gcc > suite of compilers, Yes, gcc is fantastic! In comparison, the standard Windows programming tools are ... nothing. There is nothing installed by default, nothing that exists as a standard, either for C or any other programming language. The closest contender is MSVC - and it's size and complexity makes gcc look like tcc in comparison. Yes, MSVC includes much more than just the compiler (and if you like its IDE and debugger, great). > complete dependence on 'make' "make" is an extraordinarily useful tool, and has shown its use over decades. I couldn't do my job on Windows without it. There is no doubt that some aspects of make's syntax are really tangled and complex, and some are just downright /wrong/ (such as needing tab characters for some indents, rather than allowing spaces). You can see this in the number of "make alternatives" that have appeared over the years. You can also note that despite all these alternatives, "make" is still very popular. > and the non-portable > 'configure'). "configure" exists precisely to make software portability simpler. But it is mainly portability between *nix systems. And yes, it is outdated, overly complex, and far, far slower than it need be. > Almost as though they take pride in knowing all this > arcane stuff. > I think most people rather take pride in knowing what they find useful, being willing to try something new, and being able to find the missing details when they need it. > I prefer Windows but if it merits it I will criticise that too. I fully understand preferences - I just wish you would understand that it /is/ a preference, not some sort of absolute fact. I use both Linux and Windows daily, and /prefer/ Linux for most of what I do (both at work and for leisure). But some things are easier, more efficient, or more convenient in Windows - both are useful. Sometimes I ride my bike, sometimes I take my car. Both will transport me around locally. But I don't moan that the bike is badly designed or chaotic because it uses a bar for steering rather than a wheel. > >> Nothing about it seems to >> suit your preferences or coincide with your intuition, and I don't get >> the feeling that you are forced to use it for work. A key problem Bart has is that he thinks his preferences and familiarity /are/ his "intuition", and that /his/ intuition is /everyone's/ intuition. He believes case-insensitive filing systems are "intuitive" and case-sensitive systems are "non-intuitive", when it is nothing more or less than his own familiarity. For people with a wide experience in computing, moving between Windows and Linux (or vice versa) is not a problem. There are always some things that take a little longer to find or learn, and some things that cause irritation, but you quickly find practical solutions or workarounds. For people with little computer experience, moving between systems is not a problem either. Once someone has told you how to start your browser or email program, you're good to go. The trouble is for power-users with great familiarity with one system, and who are determined to "prove" that the other system is worse in all possible ways. That is your category, Bart. You intentionally and knowingly pick the smallest and cheapest Linux system you can find, intentionally and knowingly using an unfamiliar processor. You repeatedly pick on differences (usually totally negligible things) that you label as "problems" and complain about loudly rather than spending 30 seconds reading about it. You are much like a long-term Linux user buying a "MS Surface" and complaining about poor support for a second monitor, no built-in development tools, and how counter-intuitive it is to type "ipconfig" when everyone would naturally type "ifconfig". > > There were also scare stories a few years ago that it would be > impossible to develop programs for new Windows OSes using your own tools > (making it as hard as doing stuff for iPad/iPhone or Android). I didn't > want to quit coding just yet, and Linux seemed to be the only option (as > I can't and don't want to do hardware any more). > >> The simplest >> solution would be just to leave it alone. The objective of the bazaar >> is not to dominate the skyline and win converts, but simply to provide a >> home for diverse solutions where you might find something of value. I >> don't think you have found anything of value there. > > I don't agree. I think the OS is usable once a set of problems have been > solved. But I haven't been impressed with what I'm discovering on the > way. In the meantime, the need for portability, to need to work on > either OS, means the quality of my coding has improved. > Once you open your mind to "differences" rather than "problems", you will get on far better.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-18 12:15 +0000 |
| Message-ID | <o5nm5o$5od$1@dont-email.me> |
| In reply to | #102105 |
On 18/01/2017 10:03, David Brown wrote:
> On 18/01/17 01:33, BartC wrote:
>> People seem to want to defend these things to the death (eg. case
>> sensitivity of the OS,
>
> That is a good thing, IMHO. Your preferences may vary - that's what
> preferences do.
You make it sound as though there was a way of switching off case
sensitivity in the OS (maybe in the C language too). If so, tell me how!
I'm glad sites such as Google, youtube, facebook Amazon etc have
case-insensitive searches as otherwise life would be rather more difficult.
> the chaos that typing 'man *' may cause, the
>
> I can think of plenty of ways to cause chaos on a computer, Linux or
> Windows.
The chaos I'm talking about is having params involving '*' and '?'
expand to an arbitrary set of filenames.
> names of ridiculous lengths full of "unfriendly" characters like spaces
> and brackets,
You mean like this:
$ cp hello.c "(one two three)"
$ ls "("*
(one two three)
Except that it's even worse:
$ cp hello.c ">"
$ cp hello.c "*.*"
$ cp hello.c "../hello.c"
$ ls
> *.* hello.c
(I don't know what happened to ../hello.c, maybe this time it copied it
it another directory.)
on an OS that has a 260 character limit on the total path
> length.
A filename limit is a good thing. Otherwise why bother with actual
files? Just put the content into the filename!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-18 13:59 +0100 |
| Message-ID | <o5noni$e56$1@dont-email.me> |
| In reply to | #102117 |
On 18/01/17 13:15, BartC wrote:
> On 18/01/2017 10:03, David Brown wrote:
>> On 18/01/17 01:33, BartC wrote:
>
>>> People seem to want to defend these things to the death (eg. case
>>> sensitivity of the OS,
>>
>> That is a good thing, IMHO. Your preferences may vary - that's what
>> preferences do.
>
> You make it sound as though there was a way of switching off case
> sensitivity in the OS (maybe in the C language too). If so, tell me how!
You stick to Windows and program in Pascal.
You can get bash to use case-insensitive wildcards if you like. How to
do this is left as an exercise for the reader.
>
> I'm glad sites such as Google, youtube, facebook Amazon etc have
> case-insensitive searches as otherwise life would be rather more difficult.
You'll notice that these are also very flexible with regard to spelling
mistakes, grammar, choice of vocabulary, etc. That's because the are
/search engines/, not programming languages, operating systems, or
command line interfaces.
Oh, and bash can do some spelling correction (for directory names) if
you enable it. Other shells, such as zsh and fish, can do even more.
Somehow, though, I don't think you will be happy until your computer is
like a well-trained secretary that does what you meant to say and not
what you actually said.
>
>> the chaos that typing 'man *' may cause, the
>>
>> I can think of plenty of ways to cause chaos on a computer, Linux or
>> Windows.
>
> The chaos I'm talking about is having params involving '*' and '?'
> expand to an arbitrary set of filenames.
>
They are not "arbitrary" - they are well-defined global wildcards.
>> names of ridiculous lengths full of "unfriendly" characters like spaces
>> and brackets,
>
> You mean like this:
>
> $ cp hello.c "(one two three)"
> $ ls "("*
> (one two three)
>
Of course you can create "unfriendly" filenames in Linux. The point is
that on Windows, your system is full of "unfriendly" path names right
out of the box - what /moron/ thought "Program Files (x86)" was a good
name for a directory? Certainly one that has never been near a command
line or ever typed a filename manually.
> Except that it's even worse:
>
> $ cp hello.c ">"
> $ cp hello.c "*.*"
> $ cp hello.c "../hello.c"
> $ ls
>> *.* hello.c
Yes, and note in Linux how easy it is to access such "unfriendly" names
if you really have to. Good luck dealing with a file called "*.*" in
windows, especially from the command line.
>
> (I don't know what happened to ../hello.c, maybe this time it copied it
> it another directory.)
>
> on an OS that has a 260 character limit on the total path
>> length.
>
> A filename limit is a good thing. Otherwise why bother with actual
> files? Just put the content into the filename!
>
Windows has the limit on the file /path/, not just the name. 260
characters was long in the days of 8.3 DOS names - it is easy to hit
that limit now. (Paths are also limited in Linux, but at 4K limit you
are not going to meet problems as often.)
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-18 15:45 +0000 |
| Message-ID | <o5o2g9$khg$1@dont-email.me> |
| In reply to | #102121 |
On 18/01/2017 12:59, David Brown wrote: > On 18/01/17 13:15, BartC wrote: >> You make it sound as though there was a way of switching off case >> sensitivity in the OS (maybe in the C language too). If so, tell me how! > > You stick to Windows and program in Pascal. (I've experimented with having my last static compiler being case-sensitive. But it hasn't really worked (much more of a nuisance than a blessing). The next version will go back to being case-insensitive, which means some care when declaring, but not using, foreign functions, but that's about it.) > You can get bash to use case-insensitive wildcards if you like. How to > do this is left as an exercise for the reader. > >> >> I'm glad sites such as Google, youtube, facebook Amazon etc have >> case-insensitive searches as otherwise life would be rather more difficult. > > You'll notice that these are also very flexible with regard to spelling > mistakes, grammar, choice of vocabulary, etc. That's because the are > /search engines/, not programming languages, operating systems, or > command line interfaces. They haven't always been spelling tolerant, but they've always ignored case. But OK, take web-site names and email addresses then. Obviously it would be nonsensical for www.microsoft.com to compete with www.microSoft.com, or www.microsoft.Com (or any of the 30,000 variations). For similar reasons, having case-intolerance within OS shell commands and options, even forgetting filenames, can also be a nuisance. > what /moron/ thought "Program Files (x86)" was a good > name for a directory? Something we agree on at last! This is where tab completion comes in. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-18 17:28 +0100 |
| Message-ID | <o5o50b$v03$1@dont-email.me> |
| In reply to | #102129 |
On 18/01/17 16:45, BartC wrote: > On 18/01/2017 12:59, David Brown wrote: >> On 18/01/17 13:15, BartC wrote: > >>> You make it sound as though there was a way of switching off case >>> sensitivity in the OS (maybe in the C language too). If so, tell me how! >> >> You stick to Windows and program in Pascal. > > (I've experimented with having my last static compiler being > case-sensitive. But it hasn't really worked (much more of a nuisance > than a blessing). The next version will go back to being > case-insensitive, which means some care when declaring, but not using, > foreign functions, but that's about it.) > Some languages are case sensitive, some are case insensitive. If it is /your/ language, you get to pick. I know that I strongly dislike seeing inconsistency in case usage in code, but it is possible to be consistent even if the language is insensitive - it's just harder. On the other hand, I also strongly dislike identifiers which differ only in the case of letters (with the possible exception of a type/object pair such as "Matrix matrix" in a small local block). If /I/ were making a new language, I would use UTF-8 for the character encoding and allow a lot of flexibility in the letters used. And I would certainly make it case /sensitive/, because I would hate to try to figure out the rules for case insensitivity across languages and non-ASCII letters. >> You can get bash to use case-insensitive wildcards if you like. How to >> do this is left as an exercise for the reader. >> >>> >>> I'm glad sites such as Google, youtube, facebook Amazon etc have >>> case-insensitive searches as otherwise life would be rather more >>> difficult. >> >> You'll notice that these are also very flexible with regard to spelling >> mistakes, grammar, choice of vocabulary, etc. That's because the are >> /search engines/, not programming languages, operating systems, or >> command line interfaces. > > They haven't always been spelling tolerant, but they've always ignored > case. > > But OK, take web-site names and email addresses then. Obviously it would > be nonsensical for www.microsoft.com to compete with www.microSoft.com, > or www.microsoft.Com (or any of the 30,000 variations). The "http" bit and domain names are case insensitive, at least for ASCII letters, and everything else is usually case sensitive but it is up to the web server or web application to decide. > > For similar reasons, having case-intolerance within OS shell commands > and options, even forgetting filenames, can also be a nuisance. Case sensitivity seems to work fine for most *nix users. > > >> what /moron/ thought "Program Files (x86)" was a good >> name for a directory? > > Something we agree on at last! This is where tab completion comes in. >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-18 09:30 -0800 |
| Message-ID | <772e19d8-df0f-4abf-a838-1236236a6444@googlegroups.com> |
| In reply to | #102129 |
On Wednesday, January 18, 2017 at 9:45:56 AM UTC-6, Bart wrote:
> (I've experimented with having my last static compiler being
> case-sensitive. But it hasn't really worked (much more of a nuisance
> than a blessing). The next version will go back to being
> case-insensitive, which means some care when declaring, but not using,
> foreign functions, but that's about it.)
The semantics I would like to see would require both that every usage of an
identifier precisely match the form of the declaration, *but* specify that
declaration of an inner-scope identifier will hide any outer-scope declaration
which differs only in case.
Thus, given [using C syntax, but obviously not C semantics]
extern int foo;
{
int Foo;
...
int x=foo; /***/
}
the marked statement shouldn't access the outer identifier foo (as it would
in a case-sensitive language), nor the inner identifier Foo (as it would
in a case-insensitive language), but should instead be regarded as a syntax
error. Someone wanting to access "foo" from within the function should
either use a different name for the inner identifier or else use a directive
that would define an alias for an identifier with a given exact spelling
which will not be matched against anything else.
For example, if the code started with:
extern int phoo __as("foo");
then the function would be able to access the external "foo" using the name
"phoo". While use of that directive would be discouraged in cases where
other practical alternatives exist, it could be a life-saver in cases where
it's necessary to link with code written in other languages, and which
happens to use an identifier that would conflict with a C reserved word.
For example, if for whatever reason code in another language expects to
call a function in your language named "restrict", the declaration could
be written as
void restrictions __as("restrict")(...arguments go here...);
and the definition likewise.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-18 23:18 +1300 |
| Message-ID | <ee8tntF2vaqU7@mid.individual.net> |
| In reply to | #102091 |
On 01/18/17 01:33 PM, BartC wrote: > > People seem to want to defend these things to the death (eg. case > sensitivity of the OS, the chaos that typing 'man *' may cause, the > disseminated file system, lack of standards for character/non-blocking > keyboard i/o and basic console i/o, the fantastically elaborate gcc > suite of compilers, complete dependence on 'make' and the non-portable > 'configure'). Almost as though they take pride in knowing all this > arcane stuff. You disparage the Unix filesystem layout without understanding the reasoning behind it. A number of my systems have the system filesystems (under/usr) mounted read only (for security): try doing that on Windows. Some filesystems are tuned for particular operation: try doing that on Windows. The current Linux project I am working uses neither make or gcc... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-17 21:22 +0000 |
| Message-ID | <o5m1rb$nf2$1@dont-email.me> |
| In reply to | #102073 |
On 17/01/2017 20:53, David Brown wrote: > On 17/01/17 20:26, BartC wrote: >> On 17/01/2017 14:18, David Brown wrote: >>> On 17/01/17 12:59, BartC wrote: >> >>> The standard Linux shell requires you to press >>> the "C" key for this auto-completion >> >> I don't understand. You mean "C" as a special command for >> tab-completion, or "c" to manually finish off the name? But never mind... >> > > The "C" key to finish off the name, obviously. You mean, putting the "c" at the end of "hello." to end up with "hello.c"? And minding you type "c" and not "C" as that will probably not work. If that's 'auto-completion' then I'd get my money back if I was you!
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web