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 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: /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 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-24 00:53 -0400
                        Re: The hammer is best rbowman <bowman@montana.com> - 2026-08-24 06:42 +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-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
      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

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

#90443

On 2026-08-24 00:28, vallor wrote:
> At Sun, 23 Aug 2026 13:50:30 +0200, "Carlos E.R." <robin_listas@es.invalid> wrote:
> 
>> 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.
> 
> SHRED(1)                 User Commands                 SHRED(1)
> 
> NAME
>         shred  -  overwrite  a  file  to  hide its contents, and
>         optionally delete it
> 
> SYNOPSIS
>         shred [OPTION]... FILE...
> 
> DESCRIPTION
>         Overwrite the specified FILE(s) repeatedly, in order  to
>         make  it harder for even very expensive hardware probing
>         to recover the data.

Not the same thing.


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

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

#90446 — Overwriting with random data (was: Re: /dev/tcp)

On 2026-08-24, Carlos E.R. wrote:

> On 2026-08-24 00:28, vallor wrote:
>> At Sun, 23 Aug 2026 13:50:30 +0200, "Carlos E.R." <robin_listas@es.invalid> wrote:
>
[snipping a lot to keep this shorter, apologies if I ended up snipping
too much]
>
>>> 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.
>>
>> SHRED(1)                 User Commands                 SHRED(1)
>>
>> NAME
>>         shred  -  overwrite  a  file  to  hide its contents, and
>>         optionally delete it
>>
>> SYNOPSIS
>>         shred [OPTION]... FILE...
>>
>> DESCRIPTION
>>         Overwrite the specified FILE(s) repeatedly, in order  to
>>         make  it harder for even very expensive hardware probing
>>         to recover the data.
>
> Not the same thing.

IIRC shred can do the same, and on block devices too, what's the
difference here? block sizes?

-- 
Nuno Silva

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

#90426

On 8/23/26 07:50, Carlos E.R. wrote:
> 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.

   Um ... how many GB could that cope with ?

   'Seek' counts can sometimes be supplimented
   by an 'offset' value - so basically you're
   getting the mult of two doubles. I didn't
   do it that way, and thus needed very large
   sector/track/cluster integers. An external 'C'
   pgm using really large integer types was needed.

   Anyway, it worked.

   My app could ALSO just LOOK at data, kinda put
   it into a "ghex"-looking sidebar (but with
   ASCII translation if possible). So you could
   just look, OR zap. Anyway, nothing TOO complex
   aside from the sheer size of modern mag disks.

   As useful utility. I encourage people to write
   their own.

   DID add one odd, maybe questionable, feature ...
   you could spec on the CL x-number of gigs to
   TOTALLY wipe at the beginning ... and then
   a couple numbers for "shotgun" blasting of
   later tracks. Most of the file-table/system
   stuff tends to be early on, and data with
   holes in it is "less useful". This made the
   "wipes" much faster.

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

#90444

On 2026-08-24 06:31, c186282 wrote:
> On 8/23/26 07:50, Carlos E.R. wrote:
>> 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:


>>>    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.
> 
>    Um ... how many GB could that cope with ?

I have done entire disks sized terabytes. But I don't actually use "seek".

> 
>    'Seek' counts can sometimes be supplimented
>    by an 'offset' value - so basically you're
>    getting the mult of two doubles. I didn't
>    do it that way, and thus needed very large
>    sector/track/cluster integers. An external 'C'
>    pgm using really large integer types was needed.

Can you seek not a byte, but a record or array?

Seek(var F; N: Int64)

File can be a file of some variable that is not a byte. And

type Int64 = - 9223372036854775808..9223372036854775807;

(why signed?)

Why not QWord?

type QWord = 0..18446744073709551615;


>    Anyway, it worked.
> 
>    My app could ALSO just LOOK at data, kinda put
>    it into a "ghex"-looking sidebar (but with
>    ASCII translation if possible). So you could
>    just look, OR zap. Anyway, nothing TOO complex
>    aside from the sheer size of modern mag disks.
> 
>    As useful utility. I encourage people to write
>    their own.
> 
>    DID add one odd, maybe questionable, feature ...
>    you could spec on the CL x-number of gigs to
>    TOTALLY wipe at the beginning ... and then
>    a couple numbers for "shotgun" blasting of
>    later tracks. Most of the file-table/system
>    stuff tends to be early on, and data with
>    holes in it is "less useful". This made the
>    "wipes" much faster.
> 


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

#90386

On 23/08/2026 05:01, Rich wrote:
>> Have you ever agreed with someone?
> It's kind of the troll ethos, disagreeing brings on more chaos.

LOL...

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

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

#90353

On 2026-08-22 04:57, c186282 wrote:
> 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  :-)

Instead, use encryption, on the device or the partitions.

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

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

#90363 — The hammer is best (Was: /dev/tcp)

In article <fvaplmx3co.ln2@Telcontar.valinor>,
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.

But a hammer is forever.

-- 
Trump has normalized hate.

The media has normalized Trump.

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

#90378 — Re: The hammer is best (Was: /dev/tcp)

On 8/22/26 19:50, Kenny McCormack wrote:
> In article <fvaplmx3co.ln2@Telcontar.valinor>,
> 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.

   Usually they'll write it on a Post-It and stick
   it to their monitor :-)

   Also, encryption is only really great if someone
   physically STEALS yer disk - pretty rare. If yer
   system is up and the drives unlocked then they
   can spy and steal from those far more easily.

> But a hammer is forever.

   Yep !

   When I retired I had like 25 old mag drives -
   a VERY heavy box full.

   First ran a wipe app I'd writ on them.

   Then ...

   Took 'em to The Shop, drill press ... put a
   half-inch hole through the top and platters.

   More than Good Enough.

   DID hate wasting all those neo magnets though ...
   and HAD removed them from many drives. But, it was
   bail-out time, so Rude & Crude ........

   A "cold chisel" and a big hammer works too.

   Still have a few 'mobiles' of HDD platters  :-)

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

#90379 — Re: The hammer is best

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.

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

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

#90389 — Re: The hammer is best

On 2026-08-23 11: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.

Exactly.

And in the typical business case, hammering of disks is not often done. 
Hard disks are simply repurposed, recycled, sold... usually zeroing them 
first. Encryption protects the case when zeroing is forgotten, or the 
disk breaks before that. Encryption protects against such accidents.


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


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

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

#90392 — Re: The hammer is best

On 23/08/2026 12:55, Carlos E.R. wrote:
> On 2026-08-23 11: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.
> 
> Exactly.
> 
> And in the typical business case, hammering of disks is not often done. 

It is UNIVERSALLY done in the UK.
Insurance will be voided, contracts lost  and people will get fired if 
it is not.

The big sources of usable hardware are BIG corporates - banks, insurance 
companies, travel agencies... they dump a thousand machines a year to 
recycling companies who sign in blood that the disk will be CRUSHED.

> Hard disks are simply repurposed, recycled, sold... usually zeroing them 
> first. Encryption protects the case when zeroing is forgotten, or the 
> disk breaks before that. Encryption protects against such accidents.
> 
No, they are not. Not by corporations. Some Mickey Mouse companies with 
nothing worth stealing might...


-- 
The higher up the mountainside
The greener grows the grass.
The higher up the monkey climbs
The more he shows his arse.

Traditional

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

#90410 — Re: The hammer is best

The Natural Philosopher <tnp@invalid.invalid> wrote:
>On 23/08/2026 12:55, Carlos E.R. wrote:
>> Hard disks are simply repurposed, recycled, sold... usually zeroing them 
>> first. Encryption protects the case when zeroing is forgotten, or the 
>> disk breaks before that. Encryption protects against such accidents.
>> 
>No, they are not. Not by corporations. Some Mickey Mouse companies with 
>nothing worth stealing might...

Corporations still act on the customs of the 2000 years because using
their brains costs money that doesn't land in budgets where the money
to destroy disks is already booked.

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]

#90434 — Re: The hammer is best

On 8/23/26 15:20, Marc Haber wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 23/08/2026 12:55, Carlos E.R. wrote:
>>> Hard disks are simply repurposed, recycled, sold... usually zeroing them
>>> first. Encryption protects the case when zeroing is forgotten, or the
>>> disk breaks before that. Encryption protects against such accidents.
>>>
>> No, they are not. Not by corporations. Some Mickey Mouse companies with
>> nothing worth stealing might...
> 
> Corporations still act on the customs of the 2000 years because using
> their brains costs money that doesn't land in budgets where the money
> to destroy disks is already booked.

   Ummmm ???

   Anyway, unless yer the CIA, ONE good whack with
   a ball-peen WILL ruin those HDDs. Quick and cheap.

   "Bang Bang Hillry's silver hammer cam down upon
   those phones" :-)

   SSDs ? Maybe TWO whacks. A "stun gun" applied
   to the pins will surely do it too. Sparky Sparky,
   no more chips.

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

#90450 — Re: The hammer is best

On 23/08/2026 20:20, Marc Haber wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 23/08/2026 12:55, Carlos E.R. wrote:
>>> Hard disks are simply repurposed, recycled, sold... usually zeroing them
>>> first. Encryption protects the case when zeroing is forgotten, or the
>>> disk breaks before that. Encryption protects against such accidents.
>>>
>> No, they are not. Not by corporations. Some Mickey Mouse companies with
>> nothing worth stealing might...
> 
> Corporations still act on the customs of the 2000 years because using
> their brains costs money that doesn't land in budgets where the money
> to destroy disks is already booked.
> 
No., They have the wisdom of age.
Crushing a disk loses maybe $20. Having a disks data stolen could cots 
them $billions
There is no way to be assured other than by doing $10,000 worth of 
testing that a disks data has completely been destroyed beyond foresnic 
recovery, but if the disk is crushed there is certainty.

Likewise the audit trails to determine whether or not the disk held any 
sensitive data or not are expensive to maintain and even more to trace.


$20 is a small price to pay for certainty


> Greetings
> Marc

-- 
The theory of Communism may be summed up in one sentence: Abolish all 
private property.

Karl Marx

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

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

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

csiph-web