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 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 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
      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

Page 1 of 2  [1] 2  Next page →

#90165 — /dev/tcp

What system(s) have /dev/tcp/* natively?

  $ man bash
  [...]
  REDIRECTION
  [...]
       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.
  [...]
              /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.

I don't see it on the various systems I have handy (Debian 13, Amazon
Linux 2023, Mac OS 15.7.x, NetBSD 10.1, Android 14).

Elijah
------
is it a plan9 thing?

[toc] | [next] | [standalone]

#90170

Eli the Bearded <*@eli.users.panix.com> writes:
> What system(s) have /dev/tcp/* natively?

Quite possibly none.

>   $ man bash
>   [...]
>   REDIRECTION
>   [...]
>        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.
>   [...]
>               /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.
>
> I don't see it on the various systems I have handy (Debian 13, Amazon
> Linux 2023, Mac OS 15.7.x, NetBSD 10.1, Android 14).

The documentation is wrong, at least based on the Bash 5.2.21 source in
Ubuntu. If a filename matches /dev/tcp/*/* then it will call socket &
connect, whatever exists in the local OS. The behaviour can be disabled
at build time but I see nothing that queries the target platform’s
capabilities.

> is it a plan9 thing?

I wondered that, but based on https://9p.io/sys/doc/net/net.html, no.
Plan 9 has /net/tcp but it doesn’t behave like Bash’s /dev/tcp special
case.

Solaris (and other SYSV) has a /dev/tcp but that also does not behave
like the Bash special case, it just provides you with a handle on the
TLI provider for TCP, in case you like gratuitous incompatibility.

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

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

#90174

On Wed, 19 Aug 2026 21:20:56 -0000 (UTC), Eli the Bearded wrote:

> What system(s) have /dev/tcp/* natively?

Not sure what the point of it is, when you have this
<https://manpages.debian.org/socat(1)>.

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

#90180

In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:
> On Wed, 19 Aug 2026 21:20:56 -0000 (UTC), Eli the Bearded wrote:
>> What system(s) have /dev/tcp/* natively?
> Not sure what the point of it is, when you have this
> <https://manpages.debian.org/socat(1)>.

This came up in the context of "how to test network on a system with no
root and no helpful utilities installed."

Normally I use, in preferential order: telnet, nc, perl[*], then curl to
test arbitrary sockets. If I know it runs a webserver, curl will be
first. In this case none of those were installed, and someone came up
with a jshell solution. Bash sockets were discussed, but also ruled out
because bash was not installed.

With jshell, the Java shell, something like this will print "Worked"
if it works:

  var s=new java.net.Socket();
  s.connect(new java.net.InetSocketAddress("www.google.com", 80), 3000);
  System.out.println("Worked");
  s.close();

And if it doesn't work, you get something like:

  |  Exception java.net.SocketTimeoutException: Connect timed out
  |        at NioSocketImpl.timedFinishConnect (NioSocketImpl.java:551)
  |        at NioSocketImpl.connect (NioSocketImpl.java:602)
  |        at SocksSocketImpl.connect (SocksSocketImpl.java:327)
  |        at Socket.connect (Socket.java:633)
  |        at (#2:1)

I was curious if there exist systems where any process that can open
a file (eg, /bin/sh) could use /dev/tcp to test sockets. I don't have
a real need, just a burning curiosity.

Elijah
------
[*] knows you can use python, too, but doesn't have the code to do so memorized

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

#90192

On Thu, 20 Aug 2026 00:59:41 -0000 (UTC), Eli the Bearded wrote:

> In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:
>>
>> On Wed, 19 Aug 2026 21:20:56 -0000 (UTC), Eli the Bearded wrote:
>>>
>>> What system(s) have /dev/tcp/* natively?
>>
>> Not sure what the point of it is, when you have this
>> <https://manpages.debian.org/socat(1)>.
>
> This came up in the context of "how to test network on a system with
> no root and no helpful utilities installed."

So a version of bash that supports /dev/tcp is somehow excluded from
that “no helpful utilities installed” assumption?

Sounds like a circular assumption to me, somehow. You know, where you
phrase the requirements so the only solution is the one you already
picked.

> [*] knows you can use python, too, but doesn't have the code to do
> so memorized

Why would you need to?

<https://docs.python.org/3/library/index.html>

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

#90200

On 2026-08-20, Lawrence D’Oliveiro wrote:

> On Thu, 20 Aug 2026 00:59:41 -0000 (UTC), Eli the Bearded wrote:
>
>> In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:
>>>
>>> On Wed, 19 Aug 2026 21:20:56 -0000 (UTC), Eli the Bearded wrote:
>>>>
>>>> What system(s) have /dev/tcp/* natively?
>>>
>>> Not sure what the point of it is, when you have this
>>> <https://manpages.debian.org/socat(1)>.
>>
>> This came up in the context of "how to test network on a system with
>> no root and no helpful utilities installed."
>
> So a version of bash that supports /dev/tcp is somehow excluded from
> that “no helpful utilities installed” assumption?
>
> Sounds like a circular assumption to me, somehow. You know, where you
> phrase the requirements so the only solution is the one you already
> picked.

There could be plenty of debate on whether the shell gets to be excluded
from that or not, and of how common GNU bash is, but there's another
interpretation of the question asked that does not cause the problem
you're pointing at:

The question is asking which systems have this *natively*... so, systems
where this bash feature wouldn't kick in.

(Is this specifically intended to be about Linux systems? If not,
perhaps it should be cross-posted to comp.unix.programmers?)

>> [*] knows you can use python, too, but doesn't have the code to do
>> so memorized
>
> Why would you need to?
>
> <https://docs.python.org/3/library/index.html>

You detected the circular assumption above, but you can't see the issue
with pointing to a networked resource for reference in case one doesn't
remember how to write the code to check for network connectivity?

-- 
Nuno Silva

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

#90225

In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:
> On Thu, 20 Aug 2026 00:59:41 -0000 (UTC), Eli the Bearded wrote:
>> This came up in the context of "how to test network on a system with
>> no root and no helpful utilities installed."
> So a version of bash that supports /dev/tcp is somehow excluded from
> that “no helpful utilities installed” assumption?

The system being tested did not have bash installed. Busybox provided
/bin/sh there.

> Sounds like a circular assumption to me, somehow. You know, where you
> phrase the requirements so the only solution is the one you already
> picked.

Maybe you can go reread that post you just replied to, with message id
<eli$2608192059@qaz.wtf>, and see if you can find this phrase:

   "ruled out because bash was not installed"

>> [*] knows you can use python, too, but doesn't have the code to do
>> so memorized
> Why would you need to?

It's very true that one can look things up, but also if you can do
things without looking them up, that's easier.

Elijah
------
python is a just a digression here

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

#90248

On Thu, 20 Aug 2026 18:15:27 -0000 (UTC), Eli the Bearded wrote:

> In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:
>>
>> On Thu, 20 Aug 2026 00:59:41 -0000 (UTC), Eli the Bearded wrote:
>>>
>>> This came up in the context of "how to test network on a system
>>> with no root and no helpful utilities installed."
>>
>> So a version of bash that supports /dev/tcp is somehow excluded
>> from that “no helpful utilities installed” assumption?
>
> The system being tested did not have bash installed. Busybox
> provided /bin/sh there.

I thought you said you were testing the *network*, not the *system*.

You can’t really do that (in general) without access to a proper
suite of diagnostic tools.

In such a situation, I would try one (or both) of two things:

* Reboot the machine with a SystemRescue USB stick
  <https://www.system-rescue.org/>. That way, I get unconstrained
  access to an entire system custom-designed precisely for running
  diagnostics.
* Bring in my own machine, which already has my own custom setup on
  it, and connect it to the network.

Both of these also have the advantage of ruling out screwups in the
existing OS installation.

And if you’re saying the situation would not allow me to do either of
these things, then I would not have accepted the job in the first
place.

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

#90249

On 2026-08-21, Lawrence D’Oliveiro wrote:

> On Thu, 20 Aug 2026 18:15:27 -0000 (UTC), Eli the Bearded wrote:
>
>> In comp.os.linux.misc, Lawrence DOliveiro <ldo@nz.invalid> wrote:
>>>
>>> On Thu, 20 Aug 2026 00:59:41 -0000 (UTC), Eli the Bearded wrote:
>>>>
>>>> This came up in the context of "how to test network on a system
>>>> with no root and no helpful utilities installed."
>>>
>>> So a version of bash that supports /dev/tcp is somehow excluded
>>> from that “no helpful utilities installed” assumption?
>>
>> The system being tested did not have bash installed. Busybox
>> provided /bin/sh there.
>
> I thought you said you were testing the *network*, not the *system*.
>
> You can’t really do that (in general) without access to a proper
> suite of diagnostic tools.
[...]
> And if you’re saying the situation would not allow me to do either of
> these things, then I would not have accepted the job in the first
> place.

I wonder what conversation would arise if you were locked in a room with
Angus MacGyver...


(And this starts reminding me of <http://www.xkcdb.com/5088>... (Ignore
the remark about "windows questions" and "use linux, noob", the rest is
what matters here.))

-- 
Nuno Silva

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

#90267

Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>* Reboot the machine with a SystemRescue USB stick
>  <https://www.system-rescue.org/>. That way, I get unconstrained
>  access to an entire system custom-designed precisely for running
>  diagnostics.

If you do that more often, take a look a grml (grml.org), a fine piece
of austrian software engineering.

Greetings
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

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

#90268

On Fri, 21 Aug 2026 09:52:23 +0200, Marc Haber wrote:

> Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>>
>>* Reboot the machine with a SystemRescue USB stick
>>  <https://www.system-rescue.org/>. That way, I get unconstrained
>>  access to an entire system custom-designed precisely for running
>>  diagnostics.
>
> If you do that more often, take a look a grml (grml.org), a fine
> piece of austrian software engineering.

Hmm, I see they support ARM, which SystemRescue does not. I thought
most of these Windows-on-ARM machines didn’t have drivers for Linux.

From the FAQ:

    Why is Grml using systemd?

    We’re a modern Linux distribution.

;)

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

#90269

Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>I thought
>most of these Windows-on-ARM machines didn’t have drivers for Linux.

Yes, that's still an issue. And even if there is a driver for Linux,
you need a Device Tree fitting the hardware so that the driver can
find the hardware.

Linux on ARM Notebook is still a bumpy experience. Linux runs well on
many of those ARM single-board computers like the Raspberry Pi and
many others.

Greetings
marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

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

#90302

On Fri, 21 Aug 2026 11:16:35 +0200, Marc Haber wrote:

> Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>
>> I thought most of these Windows-on-ARM machines didn’t have drivers
>> for Linux.
>
> Yes, that's still an issue. And even if there is a driver for Linux,
> you need a Device Tree fitting the hardware so that the driver can
> find the hardware.

I though that had been fixed with Aarch64 mandating some form of UEFI
for hardware discovery, so compiling a device tree in the source code
was no longer necessary.

Certainly Windows never had anything resembling device tree, so I
don’t think there’s any way it could be made to work otherwise.

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

#90324

Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>On Fri, 21 Aug 2026 11:16:35 +0200, Marc Haber wrote:
>> Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>>> I thought most of these Windows-on-ARM machines didn’t have drivers
>>> for Linux.
>>
>> Yes, that's still an issue. And even if there is a driver for Linux,
>> you need a Device Tree fitting the hardware so that the driver can
>> find the hardware.
>
>I though that had been fixed with Aarch64 mandating some form of UEFI
>for hardware discovery, so compiling a device tree in the source code
>was no longer necessary.

All that I can say is that the Raspberry Pi 4 uses device trees even
when booting via the long Firmware-uboot=grub-linux wich the = stage
being an UEFI environment. When you use the native UEFI firmware, no
device tree is available which means, for example, no accelerated
video, since the vc4 driver does device tree only.

And when I was on the last Debian conference, two participants were
trying to get an ARM Thinkpad running with Debian and were muttering
device tree, device tree all the time.

Looks to me that device trees are a big thing in ARM hardware.

Greetings
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

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

#90310

On 8/21/26 03:52, Marc Haber wrote:
> Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>> * Reboot the machine with a SystemRescue USB stick
>>   <https://www.system-rescue.org/>. That way, I get unconstrained
>>   access to an entire system custom-designed precisely for running
>>   diagnostics.
> 
> If you do that more often, take a look a grml (grml.org), a fine piece
> of austrian software engineering.
> 
> Greetings
> Marc

   Had never heard of it.

   I usually keep a stick with Kali on it for
   such emergencies, but Kali is BIG while this
   is a quarter the size. Can use one of my older
   small sticks.

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

#90207

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.

>   $ man bash
>   [...]
>   REDIRECTION
>   [...]
>        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.
>   [...]
>               /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.
> 
> I don't see it on the various systems I have handy (Debian 13, Amazon
> Linux 2023, Mac OS 15.7.x, NetBSD 10.1, Android 14).

> is it a plan9 thing?

It's a Bash feature.  Note the man page quote you provided:

>  **Bash** handles several filenames specially when they are used in 
>  redirections

These are handled by Bash, they don't exist as part of the OS (system).

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

#90219

On 8/20/26 09:50, Rich 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.
> 
>>    $ man bash
>>    [...]
>>    REDIRECTION
>>    [...]
>>         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.
>>    [...]
>>                /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.
>>
>> I don't see it on the various systems I have handy (Debian 13, Amazon
>> Linux 2023, Mac OS 15.7.x, NetBSD 10.1, Android 14).
> 
>> is it a plan9 thing?
> 
> It's a Bash feature.  Note the man page quote you provided:
> 
>>   **Bash** handles several filenames specially when they are used in
>>   redirections
> 
> 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.

   Other odd Linux tricks - how many know you can
   read/write to a disk drive that has no file
   system ? GParted does have an option that creates
   a "blank" drive. It's an old trick, squeeze in
   more raw data. To a degree, it can make that data
   a bit more "portable" because it's not tied to
   EXT?/NTFS/XFS/etc. You just need a system that
   can open the 'blank' as an I/O device.

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

#90227

c186282 <c186282@nnada.net> wrote:
>   Other odd Linux tricks - how many know you can
>   read/write to a disk drive that has no file
>   system ?

That is not a Linux trick, that's a Unix feature given that devices are 
mapped to files.

Just write your data to /dev/sda (whole disk, including boot sector) or 
/dev/sda5 (5th partition on disk).

That is where the 'dd' command is useful.  You can "clone" a disk on 
Unix (if you are root, or if the two disk device files have write 
permission for your current user) by just doing:

dd if=/dev/sda of=/dev/sdb bs=4096 

Assuming the disks use 4096 byte sectors.  

No need for extra "disk cloning" machines to actually duplicate a disk.

You can also backup the same way (although it is a rather wasteful way, 
as you also backup all the empty "free space" too):

dd if=/dev/sda of=/tmp/disk-backup bs=4096

None of this is new to anyone who's used, and understood from an admin 
perspective, a Unix system for any short length of time.

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

#90281

On 20/08/2026 18:02, c186282 wrote:
> Other odd Linux tricks - how many know you can
>    read/write to a disk drive that has no file
>    system ?
Of course. Done all the time with floppies

Just write to the raw device.

After all, at some level some part of Linux has to do that anyway even 
if it is writing to a file.


-- 
"An intellectual is a person knowledgeable in one field who speaks out 
only in others...”

Tom Wolfe

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

#90314

On 8/21/26 08:54, The Natural Philosopher wrote:
> On 20/08/2026 18:02, c186282 wrote:
>> Other odd Linux tricks - how many know you can
>>    read/write to a disk drive that has no file
>>    system ?
> Of course. Done all the time with floppies
> 
> Just write to the raw device.
> 
> After all, at some level some part of Linux has to do that anyway even 
> if it is writing to a file.

   It used to be popular for holding the max amount
   of binary data - no space wasted with the file
   system setup.

   A few years back I leveraged it for a disk-wipe
   program. Problem was that disks have become SO
   huge ... had to use M$ 128/256-bit var classes to
   access the whole thing.

   E-Disks ... can't REALLY wipe 'em alas. There
   are hidden buffers plus the wear-leveling scheme
   gets in the way. You wipe 'em the Hillary Clinton
   way - HAMMER  :-)

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web