'Find' inside loop buggy, incorrectly make up dir.
find or bash or anything has made a bit buggy behavior
for n in dircopy dircopy1 ;{
sudo find /usr/bin /usr/local -regextype posix-extended -iregex
'.*|.*' '(' -type d '(' -path '* *' -printf ''\''%p/'\''\n' -o -printf
'%p/\n' ')' -o '(' -path '* *' -printf ''\''%p'\''\n' -o -printf
'%p\n' ')' ')' -exec cp -r '{}' "$n" ';'
}
find make up bin dir. inside dircopy and target results are put there
instead of on dircopy
Re: 'Find' inside loop buggy, incorrectly make up dir.
Le 01/01/2021 à 12:12, Budi écrivait : find or bash or anything has made a bit buggy behavior Budi this is the wrong list for your question because it is 100 unrelated to Bash's bugs. Try to search the web, where there are plenty of resources to help with using the find utility to copy or move files. -- Léa Gris
Re: 'Find' inside loop buggy, incorrectly make up dir.
On Fri, Jan 01, 2021 at 06:12:32PM +0700, Budi wrote:
> find or bash or anything has made a bit buggy behavior
>
> for n in dircopy dircopy1 ;{
>
> sudo find /usr/bin /usr/local -regextype posix-extended -iregex
> '.*|.*' '(' -type d '(' -path '* *' -printf ''\''%p/'\''\n' -o -printf
> '%p/\n' ')' -o '(' -path '* *' -printf ''\''%p'\''\n' -o -printf
> '%p\n' ')' ')' -exec cp -r '{}' "$n" ';'
>
> }
>
> find make up bin dir. inside dircopy and target results are put there
> instead of on dircopy
This has nothing to do with the bash shell. It is also not surprising
that you get strange results as you are recursively copying every found
directory into your two directories dircopy and dircopy1.
That is, you copy /usr/local into dircopy recursively, then you copy
/usr/local/share into dircopy (even though it's already been copied),
then you copy /usr/local/bin etc. In some cases, depending on a file's
depth, you would copy the same files many many times.
Also note that -regextype posix-extended -iregex .*|.*' just means
"every name" since the given pattern would match all possible filenames.
Your -printf arguments contain empty strings (the first '' can be
removed from both), and they can be simplified into -printf "'%p/'\n"
and -print "'%p'\n".
Unfortunately, it's unclear what it is you really want to achieve, but
this is not the list to discuss it as it has nothing to do with bash.
You may want to try https://unix.stackexchange.com/ or some similar
place instead.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: New Feature Request
On 2020-12-27 at 13:30 -0500, Saint Michael wrote: > Yes, superglobal is great. > Example, from the manual: > " Shared Memory > Shared memory allows one or more processes to communicate via memory > that appears in all of their virtual address spaces. The pages of the > virtual memory is referenced by page table entries in each of the > sharing processes' page tables. It does not have to be at the same > address in all of the processes' virtual memory. As with all System V > IPC objects, access to shared memory areas is controlled via keys and > access rights checking. > Once the memory is being shared, there are no checks on how the > processes are using it. They must rely on other mechanisms, for > example System V semaphores, to synchronize access to the memory." > > We could allow only strings or more complex objects, but using bash- > language only, an internal mechanism, > > Is it doable? Yes. In fact, you can already do that using an interface exactly identical to file operations: # Store a string in shared memory with key 'foo' echo "Hello world" > foo # Read value of key foo var="$(
Re: SIGSEGV in GNU bash, version 5.1.4(1)-release (sparc-sun-solaris2.10)
On 12/31/20 12:31 AM, Chet Ramey wrote: > On 12/29/20 7:28 PM, Dennis Clarke wrote: >> >> Firstly as a minor nit that seems to re-appear yearly there are still >> source files in the release tarballs that are not readable to a normal >> user : >> >> # >> # find . -ls | grep '\-\-\-' >> 7348095 24 -rw--- 1 286 staff 38962 Jul 8 14:19 >> ./lib/malloc/malloc.c >> 7347442 1 -rw--- 1 286 staff 226 May 29 2020 >> ./tests/varenv20.sub >> # >> # chmod 644 ./lib/malloc/malloc.c ./tests/varenv20.sub >> >> Trivial but annoyed as it throws the compile process out the window on >> the first initial pass. Otherwise all goes well until we try to use the >> resultant bash binary. > > I'll change those. A minor annoyance at best. Hey man, thank you for getting back to me on New Years Eve ! Now that is dedication right there :-) > >> >> I was very surprised to see : >> >> alpha $ >> alpha $ dbx /opt/bw/bin/bash >> node_alpha-host_sun4u-zone_z_003-time_1609232628-pid_10009-uid_16411-gid_20002-fid_bash.core >> >> Reading bash >> core file header read successfully >> Reading ld.so.1 >> Reading libreadline.so.8 >> Reading libhistory.so.8 > > I can't reproduce this with the default configure and build options, on a > fresh install of Solaris 10 1/13 on Virtualbox. Maybe try building without > linking with an external readline library. There may be some > incompatibility between readline-8.0 and 8.1 that I'm not aware of. > Yeah, it is not exactly easy hardware to have laying around. I suspect something funny is at work here in my Fujitsu SPARC world. I was going to rebuild readline again and give it a whirl. Tomorrow maybe. Or Monday. If you want access to a build box just drop me a line with a public key. I still have these great hulking Oracle Fujitsu boxes running and I suspect I will for years. Some people really don't want to migrate code and that goes double when it is piles of Fortran IV stuff ported out of older IBM Mainframes. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
