Re: /dev/tcp

On 2026-08-24 00:28, vallor wrote:
> At Sun, 23 Aug 2026 13:50:30 +0200, "Carlos E.R." <[email protected]> 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.
> 
> 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🇪🇺;