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

Groups > comp.os.linux.misc > #90165 > unrolled thread

/dev/tcp

Back to article view | Back to comp.os.linux.misc

Contents

  /dev/tcp Eli the Bearded <*@eli.users.panix.com> - 2026-08-19 21:20 +0000
    Re: /dev/tcp Richard Kettlewell <invalid@invalid.invalid> - 2026-08-19 23:53 +0100
    Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-19 23:42 +0000
      Re: /dev/tcp Eli the Bearded <*@eli.users.panix.com> - 2026-08-20 00:59 +0000
        Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-20 03:59 +0000
          Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-20 10:10 +0100
          Re: /dev/tcp Eli the Bearded <*@eli.users.panix.com> - 2026-08-20 18:15 +0000
            Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-20 23:30 +0000
              Re: /dev/tcp Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-21 01:18 +0100
              Re: /dev/tcp Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-21 09:52 +0200
                Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-21 08:12 +0000
                  Re: /dev/tcp Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-21 11:16 +0200
                    Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-21 22:57 +0000
                      Re: /dev/tcp Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-22 06:17 +0200
                Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-21 21:50 -0400
                Re: /dev/tcp Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2026-08-24 17:42 +0300
                  Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-24 23:53 +0000
                  Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-25 02:27 -0400
              Re: /dev/tcp vallor <vallor@vallor.earth> - 2026-08-23 00:56 +0000
                Re: /dev/tcp Rich <rich@example.invalid> - 2026-08-23 04:01 +0000
                  Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-23 03:37 -0400
                    Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-08-23 13:50 +0200
                      Re: /dev/tcp vallor <vallor@vallor.earth> - 2026-08-23 22:28 +0000
                        Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-08-24 09:35 +0200
                          Overwriting with random data (was: Re: /dev/tcp) Nuno Silva <nunojsilva@invalid.invalid> - 2026-08-24 11:10 +0100
                            Re: Overwriting with random data "Carlos E.R." <robin_listas@es.invalid> - 2026-08-24 20:34 +0200
                              Re: Overwriting with random data Richard Kettlewell <invalid@invalid.invalid> - 2026-08-24 20:57 +0100
                                Re: Overwriting with random data "Carlos E.R." <robin_listas@es.invalid> - 2026-08-24 22:26 +0200
                                  Re: Overwriting with random data c186282 <c186282@nnada.net> - 2026-08-25 02:39 -0400
                                    Re: Overwriting with random data Richard Kettlewell <invalid@invalid.invalid> - 2026-08-25 08:45 +0100
                          Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-25 00:37 -0400
                      Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-24 00:31 -0400
                        Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-08-24 09:45 +0200
                    Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-08-23 12:52 +0100
                  Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-08-23 12:50 +0100
    Re: /dev/tcp Rich <rich@example.invalid> - 2026-08-20 13:50 +0000
      Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-20 13:02 -0400
        Re: /dev/tcp Rich <rich@example.invalid> - 2026-08-20 18:26 +0000
        Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-08-21 13:54 +0100
          Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-21 22:57 -0400
            Re: /dev/tcp "Carlos E.R." <robin_listas@es.invalid> - 2026-08-22 21:47 +0200
              The hammer is best (Was: /dev/tcp) gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-22 23:50 +0000
                Re: The hammer is best (Was: /dev/tcp) c186282 <c186282@nnada.net> - 2026-08-23 04:28 -0400
                Re: The hammer is best Richard Kettlewell <invalid@invalid.invalid> - 2026-08-23 10:14 +0100
                  Re: The hammer is best "Carlos E.R." <robin_listas@es.invalid> - 2026-08-23 13:55 +0200
                    Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-23 13:16 +0100
                      Re: The hammer is best Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-23 21:20 +0200
                        Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-24 02:18 -0400
                        Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-24 11:26 +0100
                          Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-25 02:06 -0400
                      Re: The hammer is best Joed Oakes <lost@noway.home.invalid> - 2026-08-23 19:42 -0400
                        Re: The hammer is best Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-23 23:56 +0000
                          Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-24 02:25 -0400
                        Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-24 01:14 +0000
                        Re: The hammer is best "Carlos E.R." <robin_listas@es.invalid> - 2026-08-24 09:50 +0200
                          Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-25 00:56 -0400
                      Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-24 00:53 -0400
                        Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-24 06:42 +0000
                          Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-24 23:34 -0400
                            Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-25 04:08 +0000
                        Re: The hammer is best The Natural Philosopher <tnp@invalid.invalid> - 2026-08-24 11:28 +0100
                          Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-25 02:07 -0400
                            Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-25 06:39 +0000
                  Re: The hammer is best c186282 <c186282@nnada.net> - 2026-08-23 22:16 -0400
        Re: /dev/tcp Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-08-21 13:41 +0100
          Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-21 22:58 +0000
          Re: /dev/tcp c186282 <c186282@nnada.net> - 2026-08-21 22:28 -0400
            ksh (was: /dev/tcp) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2026-08-24 13:56 +0100
              Bash vs. ksh - Does it matter? And the 'vi' mode thing... (Was: ksh (was: /dev/tcp)) gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-24 14:57 +0000
              Re: ksh (was: /dev/tcp) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-24 21:08 +0000
                Re: ksh (was: /dev/tcp) gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-24 21:28 +0000
                Re: ksh (was: /dev/tcp) rbowman <bowman@montana.com> - 2026-08-25 01:11 +0000
              Re: ksh c186282 <c186282@nnada.net> - 2026-08-25 02:25 -0400
                Re: ksh rbowman <bowman@montana.com> - 2026-08-25 06:52 +0000
                Re: ksh Marco Moock <mm@dorfdsl.de> - 2026-08-25 09:56 +0200
      Re: /dev/tcp Eli the Bearded <*@eli.users.panix.com> - 2026-08-20 18:22 +0000
        Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-08-21 13:57 +0100
    Re: /dev/tcp Lars Poulsen <lars@beagle-ears.com> - 2026-08-23 06:37 -0700
      Re: /dev/tcp Richard Kettlewell <invalid@invalid.invalid> - 2026-08-23 14:49 +0100
      Re: /dev/tcp The Natural Philosopher <tnp@invalid.invalid> - 2026-08-23 16:13 +0100
      Re: /dev/tcp Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-23 22:31 +0000
        Re: /dev/tcp Richard Kettlewell <invalid@invalid.invalid> - 2026-08-24 19:08 +0100

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

#90451 — Re: The hammer is best

On 24/08/2026 05:53, c186282 wrote:
> Anyway, unless you're the CIA or such, nobody is gonna
>    disassemble yer old drives and try to run a "head on
>    a stick" over them to try and recover bits of data.

Large corporate competitors might well undertake such.

-- 
The difference bweteen a psychopath and a saint is that the psychpoath 
takes what he can and gives only what he must, but the saint gives 
everything he can and takes only what he needs.

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

#90490 — Re: The hammer is best

On 8/24/26 06:28, The Natural Philosopher wrote:
> On 24/08/2026 05:53, c186282 wrote:
>> Anyway, unless you're the CIA or such, nobody is gonna
>>    disassemble yer old drives and try to run a "head on
>>    a stick" over them to try and recover bits of data.
> 
> Large corporate competitors might well undertake such.

   Think "time/resource investment -vs- likely payoff".

   Disks from CIA boxes, yes, WORTH IT. Otherwise ...

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

#90494 — Re: The hammer is best

On Tue, 25 Aug 2026 02:07:49 -0400, c186282 wrote:

> On 8/24/26 06:28, The Natural Philosopher wrote:
>> On 24/08/2026 05:53, c186282 wrote:
>>> Anyway, unless you're the CIA or such, nobody is gonna
>>>    disassemble yer old drives and try to run a "head on a stick"
>>>    over them to try and recover bits of data.
>> 
>> Large corporate competitors might well undertake such.
> 
>    Think "time/resource investment -vs- likely payoff".
> 
>    Disks from CIA boxes, yes, WORTH IT. Otherwise ...

I used to joke that if a competitor got their hands on our entire source 
code it would set them back five years. 

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

#90423 — Re: The hammer is best

On 8/23/26 05:14, Richard Kettlewell wrote:
> gazelle@shell.xmission.com (Kenny McCormack) writes:
>> Carlos E.R. <robin_listas@es.invalid> wrote:
>> ...
>>>>    are hidden buffers plus the wear-leveling scheme
>>>>    gets in the way. You wipe 'em the Hillary Clinton
>>>>    way - HAMMER :-)
>>>
>>> Instead, use encryption, on the device or the partitions.
>>
>> Hammer is better, because encryption can be worked around by holding a
>> gun to the head of the person who knows the encryption key.
> 
> My backup drives are encrypted. In principle they could be stolen from
> here, from an offsite location or in transit and if that happens I won’t
> have the opportunity to destroy it.
> 
> The chances that someone would threaten my life or liberty over it are
> negligible, but if they did, they wouldn’t need to wait for a device to
> be disposed of, they’d just turn up at my door with a weapon, RIPA
> notice or other leverage.
> 
> Physical destruction is not really relevant for most of the lifetime of
> confidential data, and encryption does actually achieve something useful
> in realistic use cases.
> 
> High value data is protected by keys that no human knows.


   However when you open the lock, anyone 'watching' can
   then get at the data.

   Physically stealing drives, very rare, tends to be noticed.

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

#90284

c186282 wrote:

> On 8/20/26 09:50, Rich wrote:
>> 
>> These are handled by Bash, they don't exist as part of the OS (system).
> 
>    Correct. I've used the /dev/tcp trick before to
>    check ports. Seems to only work with Bash. Others
>    might add it eventually, but not too likely.

According to https://mywiki.wooledge.org/BashFAQ/061 the feature was
added to bash in version 2.04 and was "Copied from / Inspired by" ksh93.

It certainly works in the versions of ksh93 I have.

-- 
Geoff Clare <netnews@gclare.org.uk>

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

#90303

On Fri, 21 Aug 2026 13:41:47 +0100, Geoff Clare wrote:

> According to https://mywiki.wooledge.org/BashFAQ/061 the feature was
> added to bash in version 2.04 and was "Copied from / Inspired by"
> ksh93.
>
> It certainly works in the versions of ksh93 I have.

Whatever happened to the idea of “do one thing, and do it well” ... ?

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

#90313

On 8/21/26 08:41, Geoff Clare wrote:
> c186282 wrote:
> 
>> On 8/20/26 09:50, Rich wrote:
>>>
>>> These are handled by Bash, they don't exist as part of the OS (system).
>>
>>     Correct. I've used the /dev/tcp trick before to
>>     check ports. Seems to only work with Bash. Others
>>     might add it eventually, but not too likely.
> 
> According to https://mywiki.wooledge.org/BashFAQ/061 the feature was
> added to bash in version 2.04 and was "Copied from / Inspired by" ksh93.
> 
> It certainly works in the versions of ksh93 I have.

   You run ksh93 ???

   Not too many Kornies left these days :-)

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

#90452 — ksh (was: /dev/tcp)

c186282 wrote:

> On 8/21/26 08:41, Geoff Clare wrote:
>> 
>> According to https://mywiki.wooledge.org/BashFAQ/061 the feature was
>> added to bash in version 2.04 and was "Copied from / Inspired by" ksh93.
>> 
>> It certainly works in the versions of ksh93 I have.
> 
>    You run ksh93 ???
> 
>    Not too many Kornies left these days :-)

Ksh has been my preferred interactive shell since I first started using
SVR4-based systems in the late 80's.

Prior to that I used something called wash, short for Warwick Shell
(a version of Bourne Shell with added interactive history, written by
some folks - students I assume - at Warwick University in the UK).
Wash's history mechanism used control characters for all the editing,
which as a vi user I hated.  Once I discovered ksh's vi mode I never
looked back.

I use bash as a fallback when ksh isn't available, but a few things
in its vi mode don't quite work the same way.

-- 
Geoff Clare <netnews@gclare.org.uk>

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

#90454 — Bash vs. ksh - Does it matter? And the 'vi' mode thing... (Was: ksh (was: /dev/tcp))

In article <0lrtlm-c0k.ln1@ID-313840.user.individual.net>,
Geoff Clare  <netnews@gclare.org.uk> wrote:
...
>I use bash as a fallback when ksh isn't available, but a few things
>in its vi mode don't quite work the same way.

I've never used ksh (other than to quickly test a quick thing here and
there), so I don't know how its vi mode works.  That said:

    1) The idea of compressing "vi" down to a single line editor is
    problematic in any case.  It will always be an approximation of the
    real thing.  In fact, if I want to do anything non-trivial in command
    line editing (in bash), I use "fc" (which invokes real vi on a temp
    file) rather than doing "inline" editing.

    2) There are a few things that bug me about bash's vi mode, but I've
    mostly accepted/gotten used to them over the years. Here are just a
    couple (there are others, but these are what comes immediately to mind):
	a) That you are in insert mode by default.  This is just not how vi
	is supposed to be used.  tcsh gets this one right.
	b) That the wildcard is "*" (as if you were in glob mode) rather
	than ".*" as it would be in real vi.

Does ksh improve on either of these points?

-- 
There's nothing more American than demanding to carry an AR-15 to
"protect yourself" but refusing to wear a mask to protect everyone else.

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

#90470 — Re: ksh (was: /dev/tcp)

On Mon, 24 Aug 2026 13:56:32 +0100, Geoff Clare wrote:

> I use bash as a fallback when ksh isn't available, but a few things
> in its vi mode don't quite work the same way.

By “vi mode” do you mean “GNU readline”?

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

#90472 — Re: ksh (was: /dev/tcp)

In article <116ibt3$373dj$2@dont-email.me>,
Lawrence DOliveiro  <ldo@nz.invalid> wrote:
>On Mon, 24 Aug 2026 13:56:32 +0100, Geoff Clare wrote:
>
>> I use bash as a fallback when ksh isn't available, but a few things
>> in its vi mode don't quite work the same way.
>
>By 'vi mode', do you mean GNU readline?

I think he is referring to the vi-like editing mode that is, in bash,
functionally provided by the 'readline' package (and usually compiled-in in
the bash executable file).

Is that what you meant?

-- 
The randomly chosen signature file that would have appeared here is more than 4-ish
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Snicker

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

#90475 — Re: ksh (was: /dev/tcp)

On Mon, 24 Aug 2026 21:08:51 -0000 (UTC), Lawrence D’Oliveiro wrote:

> On Mon, 24 Aug 2026 13:56:32 +0100, Geoff Clare wrote:
> 
>> I use bash as a fallback when ksh isn't available, but a few things in
>> its vi mode don't quite work the same way.
> 
> By “vi mode” do you mean “GNU readline”?

set -o vi

If you type a line and <Ctrl>b moves you back a character you're in 
readline's emacs mode.  If yuo see ^B you are in vi mode.

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

#90491 — Re: ksh

On 8/24/26 08:56, Geoff Clare wrote:
> c186282 wrote:
> 
>> On 8/21/26 08:41, Geoff Clare wrote:
>>>
>>> According to https://mywiki.wooledge.org/BashFAQ/061 the feature was
>>> added to bash in version 2.04 and was "Copied from / Inspired by" ksh93.
>>>
>>> It certainly works in the versions of ksh93 I have.
>>
>>     You run ksh93 ???
>>
>>     Not too many Kornies left these days :-)
> 
> Ksh has been my preferred interactive shell since I first started using
> SVR4-based systems in the late 80's.

   Well, we like what we like.

   But for a LONG LONG time, most everybody goes
   with Bash.

   DO have a c-shell installed, always do, but have
   not USED it for anything in 20 years. Also always
   install a FORTH ... but again haven't USED it for
   anything in 20+ years.

   Always install a COBOL too ... HAVE used it to make
   a few odd things - but mostly to "keep my hand in",
   nothing important.

> Prior to that I used something called wash, short for Warwick Shell
> (a version of Bourne Shell with added interactive history, written by
> some folks - students I assume - at Warwick University in the UK).
> Wash's history mechanism used control characters for all the editing,
> which as a vi user I hated.  Once I discovered ksh's vi mode I never
> looked back.
> 
> I use bash as a fallback when ksh isn't available, but a few things
> in its vi mode don't quite work the same way.

   No.

   Anyway, for an interpreted script lang these days, PYTHON.
   Massively better in every way than the old shit. Ya usually
   need ONE of the old script langs to RUN Python however, but
   there are shortcuts. Some kind of "Bash-E", ONLY meant to
   start other scripts, would not be a bad idea.

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

#90496 — Re: ksh

On Tue, 25 Aug 2026 02:25:36 -0400, c186282 wrote:

>    DO have a c-shell installed, always do, but have not USED it for
>    anything in 20 years. Also always install a FORTH ... but again
>    haven't USED it for anything in 20+ years.

https://wellys.com/posts/rp2040_forth/

I briefly thought about playing with this -- very briefly. 

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

#90502 — Re: ksh

Am 25.08.26 um 08:25 schrieb c186282:
> 
>    But for a LONG LONG time, most everybody goes
>    with Bash.

Because it is standard in most Linux distributions and they are most 
widespread now.

-- 
Gruß
Marco

Please send unsolicited mail to dustbin12@stinkedores.dorfdsl.de

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

#90226

In comp.os.linux.misc, Rich  <rich@example.invalid> wrote:
> Eli the Bearded <*@eli.users.panix.com> wrote:
>> What system(s) have /dev/tcp/* natively?
> What "systems"?  Only those with a /bin/bash compiled with this 
> "special bash feature" compiled in.

None is a potential answer.

>>        Bash handles several filenames specially when they are used in
>>        redirections,  as described  in the  following table.   If the
                                                                  ^^^^^^
>>        operating  system on  which  bash is  running  provides  these
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>        special files, bash will use them;  other wise it will emulate
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>        them internally with the behavior described below.

> It's a Bash feature.  Note the man page quote you provided:
>>  **Bash** handles several filenames specially when they are used in 
>>  redirections

Note the underlined bit. In my mind "emulate" implies there is a thing
that does this, because the dictionary definition of "emulate" is very
close to "immitate".

From WordNet (r) 3.0 (2006) [wn]:
 
  emulate
      v 1: strive to equal or match, especially by imitating; "He is
           emulating the skating skills of his older sister"
      2: imitate the function of (another system), as by modifying the
         hardware or the software
      3: compete with successfully; approach or reach equality with;
         "This artist's drawings cannot emulate his water colors"

Note how there is nothing there about "make up whole cloth" or
"completely implement without reference to something else."

Elijah
------
realizes some documentation is fiction

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

#90282

On 20/08/2026 19:22, Eli the Bearded wrote:
> Note the underlined bit. In my mind "emulate" implies there is a thing
> that does this, because the dictionary definition of "emulate" is very
> close to "imitate".

Emulation carries a strong implication of arriving at the same result by 
a radically different means, whereas imitate attempts to simply 
duplicate the method.
e.g. software models emulate the real world, they do not imitate it.



-- 
“It is hard to imagine a more stupid decision or more dangerous way of 
making decisions than by putting those decisions in the hands of people 
who pay no price for being wrong.”

Thomas Sowell

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

#90397

On 2026-08-19 14:20, Eli the Bearded wrote:
> What system(s) have /dev/tcp/* natively?
>    [...]
>                /dev/tcp/host/port
> 		  If  host  is a valid  hostname or Internet address,
> 		  and port is an integer port number or service name,
> 		  bash attempts to open the corresponding TCP socket.

After several days, we have now ascertained that nobody ever implemented 
this with a true device interface - it is a fiction implemented by the 
shell intercepting the filename and diverting it.

Which is kinda strange. It seems like it should be easier to really do 
it as a true device interface. It would be easier for quick-and-dirty 
programs than the socket interface. Maybe the problem is the DNS lookup 
would have to be done below the kernel boundary? But would it really be 
that much harder than the weird stuff done with virtual file systems?

-- 
Lars Poulsen - an old geek in Santa Barbara, California

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

#90398

Lars Poulsen <lars@beagle-ears.com> writes:
> Eli the Bearded wrote:
>> What system(s) have /dev/tcp/* natively?
>>    [...]
>>                /dev/tcp/host/port
>> 		  If  host  is a valid  hostname or Internet address,
>> 		  and port is an integer port number or service name,
>> 		  bash attempts to open the corresponding TCP socket.
>
> After several days, we have now ascertained that nobody ever
> implemented this with a true device interface - it is a fiction
> implemented by the shell intercepting the filename and diverting it.
>
> Which is kinda strange. It seems like it should be easier to really do
> it as a true device interface. It would be easier for quick-and-dirty
> programs than the socket interface.

A magic filename would only be useful if it worked everywhere or if you
were only targetting the platform(s) that supported it. All the failure
modes would have to be compressed into a single errno value.

In contrast getaddrinfo+socket+connect is only a few lines of code, it
works everywhere, and you can easily tell the end user which part of the
process failed, when it doesn’t work.

> Maybe the problem is the DNS lookup would have to be done below the
> kernel boundary? But would it really be that much harder than the
> weird stuff done with virtual file systems?

The Linux kernel can already call up to userspace to do DNS lookups:
https://docs.kernel.org/networking/dns_resolver.html

-- 
https://www.greenend.org.uk/rjk/

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

#90400

On 23/08/2026 14:37, Lars Poulsen wrote:
> On 2026-08-19 14:20, Eli the Bearded wrote:
>> What system(s) have /dev/tcp/* natively?
>>    [...]
>>                /dev/tcp/host/port
>>           If  host  is a valid  hostname or Internet address,
>>           and port is an integer port number or service name,
>>           bash attempts to open the corresponding TCP socket.
> 
> After several days, we have now ascertained that nobody ever implemented 
> this with a true device interface - it is a fiction implemented by the 
> shell intercepting the filename and diverting it.
> 

All interfaces are fiction. In this case its one implemented by the shell

> Which is kinda strange. It seems like it should be easier to really do 
> it as a true device interface. It would be easier for quick-and-dirty 
> programs than the socket interface. Maybe the problem is the DNS lookup 
> would have to be done below the kernel boundary? But would it really be 
> that much harder than the weird stuff done with virtual file systems?
> 
Sockets were always crap. There are other options for specific 
connections e.g. curl and friends.

-- 
“when things get difficult you just have to lie”

― Jean Claud Jüncker

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

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

Back to top | Article view | comp.os.linux.misc

csiph-web