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

Groups > comp.misc > #26175 > unrolled thread

terminal only for two weeks

Back to article view | Back to comp.misc

Contents

  terminal only for two weeks Retrograde <fungus@amongus.com.invalid> - 2024-11-25 13:34 +0000
    Re: terminal only for two weeks D <nospam@example.net> - 2024-11-25 22:18 +0100
    Re: terminal only for two weeks Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-25 21:52 +0000
      Re: terminal only for two weeks Mike Spencer <mds@bogus.nodomain.nowhere> - 2024-11-26 03:18 -0400
        Re: terminal only for two weeks Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-26 21:28 +0000
      Re: terminal only for two weeks yeti <yeti@tilde.institute> - 2024-11-26 09:22 +0042
        Re: terminal only for two weeks Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-26 21:24 +0000
      Re: terminal only for two weeks candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-11-30 01:20 +0000
        Re: terminal only for two weeks yeti <yeti@tilde.institute> - 2024-11-30 04:22 +0042
          Re: terminal only for two weeks candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-12-01 20:40 +0000
        Re: terminal only for two weeks Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-30 03:52 +0000
          Re: terminal only for two weeks candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-12-01 20:40 +0000
            Re: terminal only for two weeks Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-01 23:24 +0000
              Re: terminal only for two weeks candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-12-02 02:00 +0000
                Re: terminal only for two weeks Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-02 05:41 +0000
    Re: terminal only for two weeks John McCue <jmccue@qball.jmcunx.com> - 2024-11-26 03:13 +0000
      Re: terminal only for two weeks D <nospam@example.net> - 2024-11-26 10:22 +0100
        Re: terminal only for two weeks yeti <yeti@tilde.institute> - 2024-11-26 12:15 +0042
          Re: terminal only for two weeks D <nospam@example.net> - 2024-11-26 16:36 +0100
            Re: terminal only for two weeks not@telling.you.invalid (Computer Nerd Kev) - 2024-11-27 07:52 +1000
              Re: terminal only for two weeks D <nospam@example.net> - 2024-11-27 10:51 +0100
                Re: terminal only for two weeks not@telling.you.invalid (Computer Nerd Kev) - 2024-11-28 06:44 +1000
                  Re: terminal only for two weeks yeti <yeti@tilde.institute> - 2024-11-28 05:54 +0042
                  Re: terminal only for two weeks D <nospam@example.net> - 2024-11-28 10:52 +0100
                    Re: terminal only for two weeks not@telling.you.invalid (Computer Nerd Kev) - 2024-11-29 06:17 +1000
                      Re: terminal only for two weeks D <nospam@example.net> - 2024-11-28 22:05 +0100
                      Re: terminal only for two weeks yeti <yeti@tilde.institute> - 2024-11-29 02:19 +0042
                        Re: terminal only for two weeks D <nospam@example.net> - 2024-11-29 10:38 +0100
                          Re: terminal only for two weeks D <nospam@example.net> - 2024-11-29 22:39 +0100
            Re: terminal only for two weeks Mike Spencer <mds@bogus.nodomain.nowhere> - 2024-11-26 17:57 -0400
              Re: terminal only for two weeks D <nospam@example.net> - 2024-11-27 10:54 +0100
                Re: terminal only for two weeks Mike Spencer <mds@bogus.nodomain.nowhere> - 2024-11-28 01:41 -0400
                  Re: terminal only for two weeks Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-28 06:42 +0000
                  Re: terminal only for two weeks D <nospam@example.net> - 2024-11-28 10:56 +0100
                  URIs within URIs: google.com/url?q= et al. Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2024-12-20 18:42 +0000
                    Re: URIs within URIs: google.com/url?q= et al. Andy Burns <usenet@andyburns.uk> - 2024-12-20 19:03 +0000
                    Re: URIs within URIs: google.com/url?q= et al. Mike Spencer <mds@bogus.nodomain.nowhere> - 2024-12-22 01:39 -0400
              Re: terminal only for two weeks Oregonian Haruspex <no_email@invalid.invalid> - 2024-12-04 06:11 +0000
                Re: terminal only for two weeks Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-04 06:42 +0000
                  Re: terminal only for two weeks candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-12-04 14:30 +0000
                    Re: terminal only for two weeks Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-05 01:46 +0000
                      Re: terminal only for two weeks not@telling.you.invalid (Computer Nerd Kev) - 2024-12-08 07:52 +1000
                        Re: terminal only for two weeks root <NoEMail@home.org> - 2024-12-08 14:11 +0000
                          Re: terminal only for two weeks Bozo User <anthk@disroot.org> - 2025-01-12 23:01 +0000
                            Re: terminal only for two weeks D <nospam@example.net> - 2025-01-13 10:46 +0100
                              Re: terminal only for two weeks not@telling.you.invalid (Computer Nerd Kev) - 2025-01-14 06:52 +1000
                                Re: terminal only for two weeks D <nospam@example.net> - 2025-01-14 18:54 +0100
                            web Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-01-16 07:55 +0000
                              Re: web not@telling.you.invalid (Computer Nerd Kev) - 2025-01-17 07:10 +1000
                                Re: web yeti <yeti@tilde.institute> - 2025-01-17 04:58 +0042
                                  Re: web anthk <anthk@openbsd.home> - 2025-03-22 21:52 +0000
                                Re: web Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-01-18 14:05 +0000
                                  Re: web not@telling.you.invalid (Computer Nerd Kev) - 2025-01-19 09:09 +1000
                                    Re: web candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-01-29 20:10 +0000
                                      Re: web Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-04 21:42 +0000
                                  Re: web Ben Collver <bencollver@tilde.pink> - 2025-01-19 14:47 +0000
                                    Re: web yeti <yeti@tilde.institute> - 2025-01-19 16:14 +0042
                                      Re: web snipeco.2@gmail.com (Sn!pe) - 2025-01-19 16:05 +0000
                                      Re: web Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-01-19 19:15 +0000
                                      Re: web Ben Collver <bencollver@tilde.pink> - 2025-01-20 15:37 +0000
                                        Re: web Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-01-24 18:45 +0000
                                      Re: web news@zzo38computer.org.invalid - 2025-01-20 11:23 -0800
                              Re: web Dave Yeo <dave.r.yeo@gmail.com> - 2025-01-16 18:04 -0800
                          Re: terminal only for two weeks Bozo User <anthk@disroot.org> - 2025-01-12 23:01 +0000
                    Re: terminal only for two weeks yeti <yeti@tilde.institute> - 2024-12-05 06:34 +0042
                      Re: terminal only for two weeks yeti <yeti@tilde.institute> - 2025-01-16 11:42 +0042
        Re: terminal only for two weeks anthk <anthk@openbsd.home> - 2025-03-22 21:52 +0000
    Re: terminal only for two weeks Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2024-11-28 12:45 +0200
    Re: terminal only for two weeks Bozo User <anthk@disroot.org> - 2025-01-12 23:01 +0000
      Re: terminal only for two weeks Salvador Mirzo <smirzo@example.com> - 2025-01-12 22:03 -0300
        Re: terminal only for two weeks D <nospam@example.net> - 2025-01-13 10:48 +0100
          Re: terminal only for two weeks Salvador Mirzo <smirzo@example.com> - 2025-01-13 16:24 -0300
            Re: terminal only for two weeks D <nospam@example.net> - 2025-01-14 18:50 +0100
            Re: terminal only for two weeks Salvador Mirzo <smirzo@example.com> - 2025-01-15 22:10 -0300
              Re: terminal only for two weeks Rich <rich@example.invalid> - 2025-01-16 04:15 +0000
              Re: terminal only for two weeks Computer Nerd Kev <not@telling.you.invalid> - 2025-01-16 15:58 +1000
              Re: terminal only for two weeks Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-21 05:31 +0000
              Re: terminal only for two weeks Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-01-23 19:33 +0000
                Re: terminal only for two weeks Salvador Mirzo <smirzo@example.com> - 2025-02-12 13:12 -0300
                  Re: terminal only for two weeks Jerry Peters <jerry@example.invalid> - 2025-02-16 20:55 +0000
                    Re: terminal only for two weeks Salvador Mirzo <smirzo@example.com> - 2025-02-16 22:54 -0300
                      Re: terminal only for two weeks Salvador Mirzo <smirzo@example.com> - 2025-02-16 22:56 -0300
                      Re: terminal only for two weeks Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-17 03:41 +0000
                        Re: terminal only for two weeks Salvador Mirzo <smirzo@example.com> - 2025-02-19 13:02 -0300
                      Re: terminal only for two weeks kludge@panix.com (Scott Dorsey) - 2025-02-17 22:18 +0000
                        Re: terminal only for two weeks Salvador Mirzo <smirzo@example.com> - 2025-02-19 13:03 -0300

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

#26402 — Re: web

>>>>> On 2025-01-20, Ben Collver wrote:
>>>>> On 2025-01-19, yeti <yeti@tilde.institute> wrote:
>>>>> Ben Collver <bencollver@tilde.pink> wrote:

 >>> In short, gopher is not the web.  It does not use the HTTP protocol,
 >>> the HTML format, nor other web standards such as Javascript.  Gopher
 >>> is a separate protocol that is not directly viewable in mainstream
 >>> browsers such as Chrome and Mozilla.

	There's a variety of formats that modern browsers allow viewing
	directly, in addition to (X)HTML.  Such as WebM; e. g. (URI split
	for readability; tr -d \\n before use):

http://upload.wikimedia.org/wikipedia/commons/2/22/
%C2%AB%D0%9C%D0%B0%D1%81%D1%82%D0%B5%D1%80
-%D0%A2%D1%83%D0%BD%D0%BA%D0%B0%C2%BB
_%D0%BE%D1%82%D0%BA%D1%80%D1%8B%D0%B2%D0%B0%D0%B5%D1%82%D1%81%D1%8F%2C
_2020-011_092050.webm

	Given the lack of hyperlinking in WebM, I'd hesitate to call
	such a file a "webpage."  SVG does support hyperlinks, however,
	so I don't see much reason myself to be opposed to SVG webpages.

 >> I contradict.

 >> When browsers appeared, we thought of the web as what was accessible
 >> by them.  FTP, HTTP and Gopher were among this in the early days.

	For instance, per http://en.wikipedia.org/wiki/NCSA_Mosaic :

 W> Mosaic is based on the libwww library and thus supported a wide
 W> variety of Internet protocols included in the library: Archie, FTP,
 W> gopher, HTTP, NNTP, telnet, WAIS.

	My understanding is that Lynx' retains the libwww codebase to
	this day, hence its support for a variety of web protocols well
	beyond the modern notion of HTTP(S)-only web.

	Call me old-fashioned, but my understanding of what "web" is
	/is/ heavily influenced by the example of Mosaic.

 > In the dawn of the Internet some people used a service called FTPmail 
 > because it could be faster and cheaper to transfer data over email
 > than over direct Internet connections.  By your logic, one could argue
 > that FTP is email because it was historically used in email clients.

	What I think you're referring to falls under the concept of a
	/gateway./  There used to be servers that you'd send a web URI
	via email to, get it downloaded by a batch web client (such as
	Wget) there, and get the result delivered to you in a response
	email.  Possibly over a cheaper, high-latency link, such as UUCP.

	(Wouldn't make as much sense to request a JPEG this way, only
	to download it later over POP3 over SLIP, Base64 and all, now
	would it?)

	It's not dissimilar to how one can read netnews articles via
	http://al.howardknight.net/ .  By itself, that doesn't make
	netnews a part of web, nor does it make HTTP a netnews protocol
	(even if it /is/ used in this case for netnews transmission.)

	Also, "email client" is a misnomer.  An email user agent
	would commonly act as /two/ clients: an ESMTP client for mail
	submission, and, say, an IMAP client for mailbox access.

	A modern MUA, such as Thunderbird, would also embed a web browser
	so it can display HTML parts in email /as well as/ images
	referenced in those parts, including those that need retrieval
	over HTTP.  Hence HTTP client being /also/ part of the so-called
	"email client."  (Even though its use would typically be disabled
	for privacy reasons.)

	Conversely, a traditional MUA, such as BSD mailx(1), would
	contain /no/ network client code within at all, relying instead
	on system facilities, such as the conventional sendmail(1) MTA
	entrypoint.  (Or a program like esmtp(1) posing as one.)
	And (or) a program like fetchmail(1) or mbsync(1).

	Curiously enough, email transmission between hosts was
	originally implemented on top of the FTP protocol; consider, e. g.:

 rfc475> This paper describes my understanding of the results of the
 rfc475> Network Mail System meeting SRI-ARC on February 23, 1973, and
 rfc475> the implications for FTP (File Transfer Protocol).  There was
 rfc475> general agreement at the meeting that network mail function
 rfc475> should be within FTP.

 rfc475> FTP currently provides two commands for handling mail.  The MAIL
 rfc475> command allows a user to send mail via the TELNET connection
 rfc475> (the server collects the mail and determines its end by
 rfc475> searching for the character sequence "CRLF.CRLF").  The MLFL
 rfc475> (mail file) command allows a user to send mail via the data
 rfc475> connection (requires a user-FTP to handle the command but
 rfc475> transfer is more efficient as server need not search for
 rfc475> a special character sequence).  [...]

	Not only this predates the transition from Transmission Control
	/Program/ ("IPv3") to Transmission Control Protocol + Internet
	Protocol (TCP/IPv4), but apparently even the first (?) formal
	specification of the former in 1974:

 rfc-index> 0675 Specification of Internet Transmission Control Program.
 rfc-index>      V. Cerf, Y. Dalal, C. Sunshine.  December 1974.
 rfc-index>      (Obsoleted by RFC7805) (Status: HISTORIC)
 rfc-index>      (DOI: 10.17487/RFC0675)

	The dawn of the Internet, indeed.

 > One could also argue that because when browsers appeared, they could
 > view HTML content over the Server Message Block protocol, that CIFS
 > is also the web.  Such arguments strike me as disingenuous.

	I'm not aware of such browsers, aside of the fact that some
	Windows-based ones have allowed \\host\path syntax in place
	of proper URLs.  I doubt that aside of the syntax, the browser
	had any SMB/CIFS client code within itself, however.

	So far in this thread, I see two possible definitions of the
	web: one I've suggested that boils down to "documents with
	hyperlinks based on URI syntax and semantics", and the other,
	that to me sounds like "what Google says."  (I don't see Mozilla
	as a major driving force behind the web this day and age.)

	And I /do/ understand why Google would push for HTTP(S)-only
	web (even with "HTTP" now being expanded to mean /three/ similar
	in concept, but otherwise mutually incompatible	protocols.)
	And I won't envy any Google manager who'll have to explain to
	the investors a decision that lowers the profits in the short
	term, and hardly promises any tangible benefits later, such as
	the decision to add (and take responsibility maintaining) a
	Gopher client to the browser.

	I do not understand why people outside of Google have to be
	bound by the decisions of their management, however.  The web
	browser I use supported Gopher since before Google existed;
	I fail to see why "Google saying so" has to be a sufficient
	reason to at once stop deeming the protocol part of the web.

	As to the definition I've suggested, I could only add the
	requirement for the relevant protocol(s) to have at least two
	independent implementations.

	My understanding is that Gopher does have such implementations.
	No idea about CIFS, but given (if Wikipedia [1] is to be believed)
	that Microsoft has never made good use of it, it sounds doubtful.

	Hence: not web.

[1] http://en.wikipedia.org/wiki/Server_Message_Block#CIFS

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

#26374 — Re: web

yeti <yeti@tilde.institute> wrote:
> When browsers appeared, we thought of the web as what was accessible
> by them.  FTP, HTTP and Gopher were among this in the early days.

Many browsers can also display local files (which is not internet), and
many newer ones can display PDF files (whether or not they are accessed
by the internet), too, though.

> Today's big$$$-browsers converge to single protocol network file viewers
> and unluckily the smallweb browsers do too.

Some of the small web browsers do support multiple protocols and multiple
file formats. Unfortunately the major web browsers do not support such
things very well even if you add extensions, though; and they have many
other problems too other than just this, anyways.

> Let's prefer multi protocol browsers and return to all goof stuff being
> just a click away from each.
> 
> That was what the web was meant to be and we should make it exactly that
> again.
> 
> First step: Prefer writing plugins for existing browsers over creating
> more single protocol file viewers.

I think that it should be done, although you can still make up new browsers
that may support such plugins too. I also think that the protocols and the
file formats should be handled separately, so there will be one plugin for
Gemini protocol and one plugin for Gemini file format (although they will
probably be a part of the same package, since they are used together), and
one plugin for Spartan protocol (which also uses Gemini file format so you
do not need a separate plugin for Spartan file format), etc.

-- 
Don't laugh at the moon when it is day time in France.

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

#26364 — Re: web

Ivan Shmakov wrote:
...
> And even
> 	though modern browsers might fail to handle some of them,
> 	traditional ones (like Lynx and, reportedly, SeaMonkey) still
> 	support things like news:, mailto:, gopher:, and even ftp:.

My SeaMonkey needs an extension to handle gopher. I have Dooble, a QT 
browser, chromium based, that does do gopher. Someone tried to convince 
the author to support Gemini but didn't make a good enough case for it.
>
>  > Try these under lynx:
>
>  > gopher://magical.fish
>  > gopher://gopherddit.com
>  > gopher://sdf.org
>  > gopher://hngopher.com
>
>  > gemini://gemi.dev (head to news waffle)
>
> 	By the by, what's the equivalent of wget(1) for gopher:?

Curl seems to work for gopher.
Dave

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

#26334

On 2024-12-08, root <NoEMail@home.org> wrote:
> Computer Nerd Kev <not@telling.you.invalid> wrote:
>>
>> I don't know about Emacs, but for TUI browsers with Javascript
>> support ELinks is one that I'm aware of. However like the
>> experimental JS support in Netsurf it doesn't seem to be advanced
>> enough to be useful (although unlike Netsurf, ELinks uses Mozilla's
>> SpiderMonkey JS engine, so I'm not exactly sure what makes it so
>> difficult to get right).
>>
>
> I regard ELinks as worthless. At best, I hope it is a work in
> progress. I haven't tried Netsurf, but I have tried implementing,
> via jsdom, specific fetch routines for different sites of interest.
> I have found that even sites that contain json data do not provide
> consistent (across sites) methods of fetching the data. It is
> worse when the data are not as organized as json data, but it is
> distributed in unique ways for the specific site.
>  

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

#26243

candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:

> But does it support JS?

EWW?

------------------------------------------------------------------------
   Although EWW and shr.el do their best to render webpages in GNU Emacs
some websites use features which can not be properly represented or are
not implemented (e.g., JavaScript).
------------------------------------------------------------------------
                                                    ( (eww.info)Basics )
-- 
I do not bite, I just want to play.

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

#26362

I haven't yet managed to get JS (and Sixels) running with Elinks, but
there is:

    <https://sr.ht/~bptato/chawan/>

JS works at least a bit, maybe just enough for Gitea?

    <https://dev1galaxy.org/viewtopic.php?pid=53922#p53922>

Despite allowing JS and cookies I couldn't use Google[0].

Fossil's menu does open with JS disabled, but I cannot select stuff in
there.  With JS allowed it doesn't even open.

    <https://www.fossil-scm.org>

I see frequent changes in Chawan, so maybe this is the one to watch now
and maybe tomorrow stuff that glitches today may be working.

____________

[0]: But meh ... there are alternatives[1].

[1]: DDG
       <https://duckduckgo.com/>
     FrogFind
       <http://www.frogfind.com/>

-- 
4. Hitchhiker 11:
(72) "Watch the road!'' she yelped.
(73) "Shit!"

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

#27009

On 2024-11-26, D <nospam@example.net> wrote:
>
>
> On Tue, 26 Nov 2024, John McCue wrote:
>
>> Retrograde <fungus@amongus.com.invalid> wrote:
>>> From the ?text is good enough? department:
>>> Title: Using (only) a Linux terminal for my personal computing in 2024
>>> Author: Thom Holwerda
>>> Date: Sun, 24 Nov 2024 22:13:32 +0000
>>> Link: https://www.osnews.com/story/141194/using-only-a-linux-terminal-for-my-personal-computing-in-2024/
>>>
>>>
>>> A month and a bit ago,?I wondered if I could cope with a terminal-only
>>> computer[1].
>>> [?]
>>>
>>> The only way to really find out was to give it a go.
>>
>> I am glad you tried, sure it was a nice and very different
>> experience.
>>
>> <snip>
>>>
>>> Doing everything from the terminal just isn't viable for me,
>>> mostly because I didn't grow up with it.
>>
>> Fair enough, but at least you tried to see what things were
>> like for us old people.  But yes, big changes like this are
>> hard to deal with.
>>
>> I started before DOS existed on minis and I remember when
>> GUIs became a thing.  I had to be dragged kicking and
>> screaming into that environment :)  Still I pretty much live
>> in Xterms and only need a GUI for browsing and html email.
>
> Through the wonders of alpine, atleast you can do html email in the 
> terminal as well! =)
>
> I use the gui for web browsing, reading pdf:s and libreoffice. The rest 
> sits in the terminal (email, programming/scripting, tinkering, reading 
> text files).
>
> I have been thinking about moving the reading part of web browsing into 
> the terminal as well, but haven't found a browser I'm happy with. Modern 
> web sites tend to become too messed up when viewed in the terminal. Maybe 
> it would be possible to write a kind of "pre-processor" that formats web 
> sites with a text based browser in mind?
>
>> <snip>
>>
>> Nice post!
>>
>>

I just use gopher for tons of web services. From youtube search, to Internet Archive
and TPB. And IRC+Bitlbee for Jabber, Mastodon and such.

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

#26207

Retrograde <fungus@amongus.com.invalid> writes:

> Doing everything from the terminal just isn’t viable for me, mostly because I
> didn’t grow up with it.

I guess I was lucky, I was exposed to a bewildering variety of computers
as I grew up in the 80s. There was the myriad of home computers, a lot
of Commodores and Speccys but also Sharps and MSXs and whatever. Some
CP/M machines at school, there were also some early Windows PCs there,
then the GUIs like Atari ST and Amiga's Workbench, sometimes Macs.

90s, I went to the University. They had MS-DOS PCs and text terminals
connected to Unix machines. Some Sun and HP Unix workstations too but
those were for more advanced students only for which I got access
later. Funny contrast, in '91 I got a summer job in a university
department which was all Macs. Looking back, it seems so radical that I
had dual displays and a "huge" 17" monitor to work on way back
then. Even if the other display was the minimal one integrated to the
boxy Mac.

In the meantime, my home computing went from a Commodore 64 to MS-DOS
PC, then dual booting that with OS/2 and some Linux experiments. Games
went to Windows so that MS-DOS became Windows 98 and XP and 7 and
10. Late 90s Linux experiments became permanent when I learned of Debian
Stable. OS/2 disappeared when picking supported hardware for it got too
tiresome.

Work, started mid-90s with Sun Unix workstations until I was kicked to
Office land. That was an awful time and when I escaped, it's been much
the same, Windows PC on the desk, Unix and later Linux server
somewhere. Oh, one job actually provided a Linux workstation under the
desk in addition to a Windows laptop but that was one time.

But to the topic, text only in 2024? I don't think so. Web browsing and
email, just no. Sure I just used Lynx on a Linux server at work to check
the proxy settings are correct and I do use mutt to teach misses to my
spam filter but that's pretty much it. For me, the email I get is HTML
with pictures from commercial sources. Very little personal
correspondence over email these days and mailing lists I get via NNTP
and gmane.

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

#26335

On 2024-11-25, Retrograde <fungus@amongus.com.invalid> wrote:
> From the «text is good enough» department:
> Title: Using (only) a Linux terminal for my personal computing in 2024
> Author: Thom Holwerda
> Date: Sun, 24 Nov 2024 22:13:32 +0000
> Link: https://www.osnews.com/story/141194/using-only-a-linux-terminal-for-my-personal-computing-in-2024/
>
>
> A month and a bit ago, I wondered if I could cope with a terminal-only
> computer[1].
> […]
>
> The only way to really find out was to give it a go.
>
> My goal was to see what it was like to use a terminal-only computer for my
> personal computing for two weeks, and more if I fancied it.
> ↫ Neil’s blog[2]
>
> I tried to do this too, once.
>
> Once.
>
> Doing everything from the terminal just isn’t viable for me, mostly because I
> didn’t grow up with it. Our family’s first computer ran MS-DOS (with a Windows
> 3.1 installation we never used), and I’m pretty sure the experience of using
> MS-DOS as my first CLI ruined me for life. My mental model for computing didn’t
> start forming properly until Windows 95 came out, and as such, computing is
> inherently graphical for me, and no matter how many amazing CLI and TUI
> applications are out there – and there are many, many amazing ones – my brain
> just isn’t compatible with it.
>
> There are a few tasks I prefer doing with the command line, like updating my
> computers or editing system files using Nano, but for everything else I’m just
> faster and more comfortable with a graphical user interface. This comes down to
> not knowing most commands by heart, and often not even knowing the options and
> flags for the most basic of commands, meaning even very basic operations that
> people comfortable using the command line do without even thinking, take me
> ages.
>
> I’m glad any modern Linux distribution – I use Fedora KDE on all my computers –
> offers both paths for almost anything you could do on your computer, and unless
> I specifically opt to do so, I literally – literally literally – never have to
> touch the command line.
>
> Links:
> [1]: https://neilzone.co.uk/2024/10/could-i-cope-with-a-terminal-only-computer/ (link)
> [2]: https://neilzone.co.uk/2024/11/using-only-a-linux-terminal-for-my-personal-computing-in-2024/ (link)

In my case, I use cwm+uxterm+a bunch of cli/tui apps, such as profanity, 
catgirl, mocp... and the only X software I use are sxiv, mpv and mupdf.
Oh, and GV for a random PostScript file. That's it.

If you can I can post my setup. It's megafast.
Ah, no, I forgot: xload and xlock, which just lie there.
Anyway, it's like an advanced terminal from a different future.

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

#26337

Bozo User <anthk@disroot.org> writes:

[...]

> In my case, I use cwm+uxterm+a bunch of cli/tui apps, such as profanity, 
> catgirl, mocp... and the only X software I use are sxiv, mpv and mupdf.
> Oh, and GV for a random PostScript file. That's it.

I too run cwm+uxterm!  But then I add the GNU EMACS on top.  

Thanks for mentioning mupdf---fast and nice.  I wonder if it can display
the outline of a pdf (if available).

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

#26341

On Sun, 12 Jan 2025, Salvador Mirzo wrote:

> Bozo User <anthk@disroot.org> writes:
>
> [...]
>
>> In my case, I use cwm+uxterm+a bunch of cli/tui apps, such as profanity,
>> catgirl, mocp... and the only X software I use are sxiv, mpv and mupdf.
>> Oh, and GV for a random PostScript file. That's it.
>
> I too run cwm+uxterm!  But then I add the GNU EMACS on top.
>
> Thanks for mentioning mupdf---fast and nice.  I wonder if it can display
> the outline of a pdf (if available).
>

I use qpdf. Has sessions, and is fairly light weight.

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

#26346

D <nospam@example.net> writes:

> On Sun, 12 Jan 2025, Salvador Mirzo wrote:
>
>> Bozo User <anthk@disroot.org> writes:
>>
>> [...]
>>
>>> In my case, I use cwm+uxterm+a bunch of cli/tui apps, such as profanity,
>>> catgirl, mocp... and the only X software I use are sxiv, mpv and mupdf.
>>> Oh, and GV for a random PostScript file. That's it.
>>
>> I too run cwm+uxterm!  But then I add the GNU EMACS on top.
>>
>> Thanks for mentioning mupdf---fast and nice.  I wonder if it can display
>> the outline of a pdf (if available).
>>
>
> I use qpdf. Has sessions, and is fairly light weight.

Wonderful!  Pretty nice as well.  Very easy to use.  Now, it can't seem
to use lpr for printing?  That's how I print. :) But I can workaround it
by figuring out how to tell lpr to tell my printer to only print a few
pages I'm interested in and then use the command line.  Thanks for
mentioning qpdf.

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

#26350

On Mon, 13 Jan 2025, Salvador Mirzo wrote:

> D <nospam@example.net> writes:
>
>> On Sun, 12 Jan 2025, Salvador Mirzo wrote:
>>
>>> Bozo User <anthk@disroot.org> writes:
>>>
>>> [...]
>>>
>>>> In my case, I use cwm+uxterm+a bunch of cli/tui apps, such as profanity,
>>>> catgirl, mocp... and the only X software I use are sxiv, mpv and mupdf.
>>>> Oh, and GV for a random PostScript file. That's it.
>>>
>>> I too run cwm+uxterm!  But then I add the GNU EMACS on top.
>>>
>>> Thanks for mentioning mupdf---fast and nice.  I wonder if it can display
>>> the outline of a pdf (if available).
>>>
>>
>> I use qpdf. Has sessions, and is fairly light weight.
>
> Wonderful!  Pretty nice as well.  Very easy to use.  Now, it can't seem
> to use lpr for printing?  That's how I print. :) But I can workaround it
> by figuring out how to tell lpr to tell my printer to only print a few
> pages I'm interested in and then use the command line.  Thanks for
> mentioning qpdf.
>

You're welcome! =)

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

#26358

Salvador Mirzo <smirzo@example.com> writes:

[...]

>> I use qpdf. Has sessions, and is fairly light weight.
>
> Wonderful!  Pretty nice as well.  Very easy to use.  Now, it can't seem
> to use lpr for printing?  That's how I print. :) But I can workaround it
> by figuring out how to tell lpr to tell my printer to only print a few
> pages I'm interested in and then use the command line.  Thanks for
> mentioning qpdf.

I suspect I imagine wrong how things actually work. I thought perhaps
there would be a command line such as ``lpr --pages 7-14''.  Now I
believe a program like evince generates a PostScript of the pages you
asked it to and then sends this complete PostScript document of the
pages you requested to a pipe or file on disk that lpr sends to the
printer.  So, if qpdf doesn't do the same, I'm out of luck in terms of
printing with lpr.  But I think I can find a program that takes page
ranges and transformations like scaling and produces a PostScript
document that I can send to lpr, so I can use qpdfview and use the
command line to print stuff out.

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

#26359

Salvador Mirzo <smirzo@example.com> wrote:
> Salvador Mirzo <smirzo@example.com> writes:
> 
> [...]
> 
>>> I use qpdf. Has sessions, and is fairly light weight.
>>
>> Wonderful!  Pretty nice as well.  Very easy to use.  Now, it can't seem
>> to use lpr for printing?  That's how I print. :) But I can workaround it
>> by figuring out how to tell lpr to tell my printer to only print a few
>> pages I'm interested in and then use the command line.  Thanks for
>> mentioning qpdf.
> 
> I suspect I imagine wrong how things actually work. I thought perhaps
> there would be a command line such as ``lpr --pages 7-14''.  Now I
> believe a program like evince generates a PostScript of the pages you
> asked it to and then sends this complete PostScript document of the
> pages you requested to a pipe or file on disk that lpr sends to the
> printer.

Yes, selecting "which pages" happens before the result gets sent to lpr 
(or cups).

> But I think I can find a program that takes page ranges and 
> transformations like scaling and produces a PostScript document that 
> I can send to lpr, so I can use qpdfview and use the command line to 
> print stuff out.

If you are dealing with pdf files, then pdftk 
<https://en.wikipedia.org/wiki/PDFtk> works very well of doing various 
transforms on pdf files (including selecting a subset of pages, that do 
not have to all be contiguous).

If you have actual postscript files, you can use ghostscript from the 
command line to "distill" them to pdf (note ghostscrpts "pdfwrite" 
output driver) and then use pdftk for further transforming.

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

#26360

Salvador Mirzo <smirzo@example.com> wrote:
> Salvador Mirzo <smirzo@example.com> writes:
>> Wonderful!  Pretty nice as well.  Very easy to use.  Now, it can't seem
>> to use lpr for printing?  That's how I print. :) But I can workaround it
>> by figuring out how to tell lpr to tell my printer to only print a few
>> pages I'm interested in and then use the command line.  Thanks for
>> mentioning qpdf.
> 
> I suspect I imagine wrong how things actually work. I thought perhaps
> there would be a command line such as ``lpr --pages 7-14''.  Now I
> believe a program like evince generates a PostScript of the pages you
> asked it to and then sends this complete PostScript document of the
> pages you requested to a pipe or file on disk that lpr sends to the
> printer.  So, if qpdf doesn't do the same, I'm out of luck in terms of
> printing with lpr.  But I think I can find a program that takes page
> ranges and transformations like scaling and produces a PostScript
> document that I can send to lpr, so I can use qpdfview and use the
> command line to print stuff out.

If you want a Postscript file of a page range from a PDF, convert the
PDF to Postscript first then use psselect from psutils. Or use the
"save marked" function in gv, which I personally use as my default
PDF viewer.

-- 
__          __
#_ < |\| |< _#

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

#26376

On Wed, 15 Jan 2025 22:10:38 -0300, Salvador Mirzo wrote:

> I thought perhaps there would be a command line such as
> ``lpr --pages 7-14''.

<https://manpages.debian.org/lp(1)>:

   -P page-list
        Specifies which pages to print in the document. The list can
        contain a list of numbers and ranges (#-#) separated by
        commas, e.g., "1,3-5,16". The page numbers refer to the output
        pages and not the document's original pages - options like
        "number-up" can affect the numbering of the pages.

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

#26395

>>>>> On 2025-01-16, Salvador Mirzo wrote:

 > I suspect I imagine wrong how things actually work.  I thought
 > perhaps there would be a command line such as ``lpr --pages 7-14''.

	As has already been pointed in this thread, CUPS, a fairly
	common choice for a printer spooler in GNU/Linux systems,
	provides lp(1) command that does have just such an option.

 > Now I believe a program like evince generates a PostScript of
 > the pages you asked it to and then sends this complete PostScript
 > document of the pages you requested to a pipe or file on disk
 > that lpr sends to the printer.

	AIUI, traditional lpd(8) / lpr(1) do require the file to be
	preprocessed in such a way before it is submitted for printing,
	but even then, they do /not/ require for the file to be
	PostScript: it's possible to setup the respective filters to
	accept other formats, such as PDF.

 > So, if qpdf doesn't do the same, I'm out of luck in terms of
 > printing with lpr.  But I think I can find a program that takes
 > page ranges and transformations like scaling and produces a
 > PostScript document that I can send to lpr, so I can use qpdfview
 > and use the command line to print stuff out.

	I'm not too familiar with qpdf(1) (and I don't think I've ever
	used qpdfview [*]), but it does have a --pages option.  E. g.:

$ qpdf  --empty --pages in.pdf 5-8 -- out.pdf 
$ qpdf  in.pdf --pages . 5-8 -- out.pdf 

	(The second variant preserves the input document metadata,
	which isn't probably of much use for printing anyway.)

	... A somewhat little-known fact is that once uncompressed, PDF
	is largely a text file (perhaps unsurprising, given it comes
	from the same company that created PostScript), though employing
	byte offsets rather unrestrictedly.

	qpdf(1) has a --qdf option that undoes compressesion and annotates
	the file in such a way that the companion fix-qdf program can
	fix the byte offsets, at least in certain cases, thus allowing the
	PDF file to be edited with a text editor.  (Though probably using
	a library, such as PDF::API2 for Perl, would be more practical
	than trying to, say, adapt sed(1) for automated edits in this case.)

    [*] Given a choice, I tend to prefer HTML.  If the document I'm
	interested in is only available in a PDF version, I tend to
	use pdftotext(1).  If that fails to produce a legible version,
	I resort to Zathura, preferring it mostly for its UI.

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

#26437

Ivan Shmakov <ivan@siamics.netREMOVE.invalid> writes:

>>>>>> On 2025-01-16, Salvador Mirzo wrote:
>
>  > I suspect I imagine wrong how things actually work.  I thought
>  > perhaps there would be a command line such as ``lpr --pages 7-14''.
>
> 	As has already been pointed in this thread, CUPS, a fairly
> 	common choice for a printer spooler in GNU/Linux systems,
> 	provides lp(1) command that does have just such an option.

Thanks for the information.  It turns out I'm not being able to print
two-sided-long-edge with CUPS and my Brother HL-L2360DW.  I resorted to
using /etc/printcap and lpd's lpr (not CUPS's lpr) because I can then
set my printer to always do two-sided-long-edge, which is nearly 100% of
the way I print.

>  > Now I believe a program like evince generates a PostScript of
>  > the pages you asked it to and then sends this complete PostScript
>  > document of the pages you requested to a pipe or file on disk
>  > that lpr sends to the printer.
>
> 	AIUI, traditional lpd(8) / lpr(1) do require the file to be
> 	preprocessed in such a way before it is submitted for printing,
> 	but even then, they do /not/ require for the file to be
> 	PostScript: it's possible to setup the respective filters to
> 	accept other formats, such as PDF.

That's what I did as well.  I use a filter called ps2pcl.

lp|remote|brother|Brother HL-L2360DW:\
  :lp=9100@BRWB052162167A6:\
  :if=/usr/local/libexec/ps2pcl:\
  :sh:sd=/var/spool/output/lpd:\
  :lf=/var/log/lpd-errs:

But today I learned that the Brother HL-L2360DW supports PostScript and
I was able to set it up that way with CUPS.  I just don't use because I
never want two-sided-short-edge or one-sided, which is all I can get
with CUPS for whatever reason.

>  > So, if qpdf doesn't do the same, I'm out of luck in terms of
>  > printing with lpr.  But I think I can find a program that takes
>  > page ranges and transformations like scaling and produces a
>  > PostScript document that I can send to lpr, so I can use qpdfview
>  > and use the command line to print stuff out.
>
> 	I'm not too familiar with qpdf(1) (and I don't think I've ever
> 	used qpdfview [*]), but it does have a --pages option.  E. g.:

Turns out qpdfview is a pretty usable PDF viewer and it's the one I'm
using the most here.  I think qpdfview is the closest thing to
SumatraPDF (on Windows), my favorite.

> $ qpdf --empty --pages in.pdf 5-8 -- out.pdf
> $ qpdf  in.pdf --pages . 5-8 -- out.pdf 

Thanks!  That works.

> 	(The second variant preserves the input document metadata,
> 	which isn't probably of much use for printing anyway.)

Good to know.  Sometimes we produce PDF for screen viewing.

> 	... A somewhat little-known fact is that once uncompressed, PDF
> 	is largely a text file (perhaps unsurprising, given it comes
> 	from the same company that created PostScript), though employing
> 	byte offsets rather unrestrictedly.
>
> 	qpdf(1) has a --qdf option that undoes compressesion and annotates
> 	the file in such a way that the companion fix-qdf program can
> 	fix the byte offsets, at least in certain cases, thus allowing the
> 	PDF file to be edited with a text editor.  (Though probably using
> 	a library, such as PDF::API2 for Perl, would be more practical
> 	than trying to, say, adapt sed(1) for automated edits in this case.)

You seem to know a lot about PostScript.  So here's a question.  When I
want to print two-sided-long-edge, is that a command included in the
PostScript document itself (and then sent to the printer)?

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

#26459

Salvador Mirzo <smirzo@example.com> wrote:
> Ivan Shmakov <ivan@siamics.netREMOVE.invalid> writes:
> 
>>>>>>> On 2025-01-16, Salvador Mirzo wrote:
>>
>>  > I suspect I imagine wrong how things actually work.  I thought
>>  > perhaps there would be a command line such as ``lpr --pages 7-14''.
>>
>>       As has already been pointed in this thread, CUPS, a fairly
>>       common choice for a printer spooler in GNU/Linux systems,
>>       provides lp(1) command that does have just such an option.
> 
> Thanks for the information.  It turns out I'm not being able to print
> two-sided-long-edge with CUPS and my Brother HL-L2360DW.  I resorted to
> using /etc/printcap and lpd's lpr (not CUPS's lpr) because I can then
> set my printer to always do two-sided-long-edge, which is nearly 100% of
> the way I print.

Sounds like an incorrect PPD, which is where the various options come
from.
I have a HL220dw and CUPS supports both simplex and duplex printing,
selectable at the time I print.

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

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

Back to top | Article view | comp.misc

csiph-web