Re: /dev/tcp

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 <[email protected]> wrote:
>>>> At Thu, 20 Aug 2026 23:30:40 -0000 (UTC), Lawrence D’Oliveiro 
>>>> <[email protected]> wrote:
>>>>
>>>>> On Thu, 20 Aug 2026 18:15:27 -0000 (UTC), Eli the Bearded wrote:
>>>>>
>>>>>> In comp.os.linux.misc, Lawrence DOliveiro <[email protected]> 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.