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

Page 1 of 3  [1] 2 3  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]

#90367

At Thu, 20 Aug 2026 23:30:40 -0000 (UTC), Lawrence D’Oliveiro <ldo@nz.invalid> 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.
> 
> 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.

Have you ever agreed with someone?

-- 
-v System76 Thelio Mega v1.1 x86_64 Mem: 258G
   OS: Linux 7.2.0 D: Mint 22.3 DE: Xfce 4.18 (X11)
   NVIDIA GeForce RTX 3090Ti (24G) (610.57.04)
   "Never hit a man with glasses. Use your fist!"

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

#90370

vallor <vallor@vallor.earth> wrote:
> At Thu, 20 Aug 2026 23:30:40 -0000 (UTC), Lawrence D’Oliveiro <ldo@nz.invalid> 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.
>> 
>> 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.
> 
> Have you ever agreed with someone?

It's kind of the troll ethos, disagreeing brings on more chaos.

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

#90376

On 8/23/26 00:01, Rich wrote:
> vallor <vallor@vallor.earth> wrote:
>> At Thu, 20 Aug 2026 23:30:40 -0000 (UTC), Lawrence D’Oliveiro <ldo@nz.invalid> 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.
>>>
>>> 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.
>>
>> Have you ever agreed with someone?
> 
> It's kind of the troll ethos, disagreeing brings on more chaos.


   There are always a few ... being negative/disagreeable
   or, worse, All-Superior is Their Main Thing. They feel
   they "Gain Power" that way.

   No, I'm not basing that on Freud or Jung - just long
   experience.

   I pref the "Let's All Get Along" approach. Everything
   goes MUCH smoother and solutions, rather than conflict,
   is the usual result.

   ANYway, /dev/tcp does have uses. It's worth exploring.
   Maybe YOU can find a use to suit YOUR needs/desires.
   I used it for a custom disk-scan/wipe app (had to
   use a 'C' module because huge track/cluster/byte numbers
   were needed for modern mag drives - the main app was
   in Lazarus for the pretty display and buttons).

   Note Lazarus/FPC *says* it supports huge seek numbers
   but DOESN'T ... limited to maybe 4gb.

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

#90387

On 2026-08-23 09:37, c186282 wrote:
> On 8/23/26 00:01, Rich wrote:
>> vallor <vallor@vallor.earth> wrote:
>>> At Thu, 20 Aug 2026 23:30:40 -0000 (UTC), Lawrence D’Oliveiro 
>>> <ldo@nz.invalid> 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.
>>>>
>>>> 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.
>>>
>>> Have you ever agreed with someone?
>>
>> It's kind of the troll ethos, disagreeing brings on more chaos.
> 
> 
>    There are always a few ... being negative/disagreeable
>    or, worse, All-Superior is Their Main Thing. They feel
>    they "Gain Power" that way.
> 
>    No, I'm not basing that on Freud or Jung - just long
>    experience.
> 
>    I pref the "Let's All Get Along" approach. Everything
>    goes MUCH smoother and solutions, rather than conflict,
>    is the usual result.
> 
>    ANYway, /dev/tcp does have uses. It's worth exploring.
>    Maybe YOU can find a use to suit YOUR needs/desires.
>    I used it for a custom disk-scan/wipe app (had to
>    use a 'C' module because huge track/cluster/byte numbers
>    were needed for modern mag drives - the main app was
>    in Lazarus for the pretty display and buttons).
> 
>    Note Lazarus/FPC *says* it supports huge seek numbers
>    but DOESN'T ... limited to maybe 4gb.

I wrote a program that writes bytes on big partitions.


excerpted:

const
      sourcefilename = './BigRandom';
      rawdest: string = '';     // example: '/dev/sda11'

      shuflecount = 1024;
      arraysize = 1023;
      ChunkSz=1048576;
type
      tCacho= array [1..ChunkSz] of byte;

var
    Fin, Fout: file of tCacho;
    gotresult: Word;

    BigData : array [1..shuflecount] of tCacho;
    OutputIndex : Int64;	// counts MiB written.


begin

// writes one MiB
       {$I-}write(Fout,BigData[RandomIndex]);{$I+}
       gotresult:= ioresult;



The purpose of the program is to fast fill a partition or disk with 
nearly true random data. It is as fast as dd could be.



-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

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

#90388

On 23/08/2026 08:37, c186282 wrote:
> There are always a few ... being negative/disagreeable
>    or, worse, All-Superior is Their Main Thing. They feel
>    they "Gain Power" that way.

I think they just get a kick out of being responded to. It's sort of an 
idle occupation, like swatting flies or doodling. Piss someone off on 
the Internet.

Imagine some guy on second line support who spends his life on front of 
a screen with nothing to do until shit happens

-- 
"The great thing about Glasgow is that if there's a nuclear attack it'll 
look exactly the same afterwards."

Billy Connolly

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web