Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #267261

Re: find and it uncommon syntax - grrrrrrrrr

Show all headers | View raw

On 2/10/24 16:07, Greg Wooledge wrote:
> On Sat, Feb 10, 2024 at 02:58:24PM -0600, Nicholas Geovanis wrote:
>> On Sat, Feb 10, 2024, 2:46 PM gene heskett <gheskett@shentel.net> wrote:
>>
>>> Greetings;
>>>
>>> I have misplaced file someplace in /home/gene.
>>> its name is bpim5*shelf.scad
>>>
>>
>> Assuming that you are searching in the current working directory:
>>   find bpim*  -print | grep 'shelf.scad'
> 
> That's not correct.  The argument(s) that immediately follow find should
> be the starting point(s) where it will begin its search.  Normally these
> would be directories, especially the "." directory, which is actually
> the default in GNU find (but not a default in POSIX find).
> 
> This command would only work if the file Gene's looking for happens to
> be in his home directory, *or*, if the file he's looking for happens to
> be underneath a *directory* whose name matches the bpim* glob.  This is
> possible, but I wouldn't count on it.
> 
Especially here. I resaved it, after a couple mods, in 
3dp-stf/genes-nas.  So searching thru all the children of "." should be 
the expected behavious. But finding that fraudulent pile of 2T disks was 
as bogus as a $3 bill, upsets my plans. The only usb-sata adapter I 
trust is StarTech, and its cable is 3x longer than I need. This bogus 
drive came sealed in a case that I had printed supports for that fit in 
2 shelf spaces, leaving room in the bottom of the care for a psu.  The 
sata package is bigger but would take 3 spaces for 6 of them, exiling 
the psu external to the cage.  So this job now printing is 4 more 
shelves, w/o the pi bolt pattern.  3dprinting is hard on memory, I've 
12G of 3dp.stf now.  Slicers and such are plain stupid, generating as 
much as 2 gigabytes for one complex part that takes 3 days to run. I've 
written 3 days jobs for a milling machine In 90 LOC because linuxcnc 
understands loops, none of the slicers or machines do, so the file you 
feed the printer is totally unrolled. And 10 to 30 times the size needed 
if the part file was converted from additive to subtractive.  It may get 
there, but probably after I miss roll call.

Thanks Greg.  Take care.
> .

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

find and it uncommon syntax - grrrrrrrrr gene heskett <gheskett@shentel.net> - 2024-02-10 21:50 +0100
  Re: find and it uncommon syntax - grrrrrrrrr Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-02-10 22:00 +0100
    Re: find and it uncommon syntax - grrrrrrrrr Greg Wooledge <greg@wooledge.org> - 2024-02-10 22:10 +0100
      Re: find and it uncommon syntax - grrrrrrrrr gene heskett <gheskett@shentel.net> - 2024-02-11 01:30 +0100
  Re: find and it uncommon syntax - grrrrrrrrr Greg Wooledge <greg@wooledge.org> - 2024-02-10 22:00 +0100
    Re: find and it uncommon syntax - grrrrrrrrr gene heskett <gheskett@shentel.net> - 2024-02-11 00:10 +0100
      Re: find and it uncommon syntax - grrrrrrrrr Andy Smith <andy@strugglers.net> - 2024-02-11 00:30 +0100
  Re: find and it uncommon syntax - grrrrrrrrr Andy Smith <andy@strugglers.net> - 2024-02-11 00:30 +0100

csiph-web