Is there a problem with the Gnuwin32 port of "find"? It sort of works on my Windows XP command line, but I get blank stares when I try using file name pattern matching function. It's from "findutils-4.2.20" package. Had to rename to "gfind.exe" so Windows wouldn't confuse with CMD.EXE's "find".
Some samples from my Windows console:
C:\PROGRA~1\GnuWin32\doc\findutils\4.2.20\findutils-4.2.20>gfind .
.
./find.chm
./find.dvi.gz
./find.GID
./find.hlp
./find.html
./find.pdf
./find.ps.gz
That works.
Again, the following works:
C:\PROGRA~1\GnuWin32\doc\findutils\4.2.20\findutils-4.2.20>gfind . -ls
1970324837321105 0 drw-rw-rw- 2 cjohns89 0 0 Jun 11:34 .
1688849860610677 128 -rw-rw-rw- 1 cjohns89 0 130729 Mar 2005 ./fin
d.chm
1688849860610679 76 -rw-rw-rw- 1 cjohns89 0 74301 Mar 2005 ./fin
d.dvi.gz
21673573207016133 20 -rw-rw-rw- 1 cjohns89 0 16826 Jun 21:05 ./fi
nd.GID
1688849860610681 152 -rw-rw-rw- 1 cjohns89 0 154036 Mar 2005 ./fin
d.hlp
1688849860610683 224 -rw-rw-rw- 1 cjohns89 0 226750 Mar 2005 ./fin
d.html
1688849860610684 372 -rw-rw-rw- 1 cjohns89 0 379300 Mar 2005 ./fin
d.pdf
1688849860610685 200 -rw-rw-rw- 1 cjohns89 0 201163 Mar 2005 ./fin
d.ps.gz
But this doesn't do squat.
C:\PROGRA~1\GnuWin32\doc\findutils\4.2.20\findutils-4.2.20>gfind . -iname '*.pdf
' -ls
It just returns to the prompt. Am I (a novice) just mistaken in my use of syntax or is there a bug?
Chuck wrote:
gfind . -iname '*.pdf ' -ls
It's better without the apostrophe, since the Windows XP command line is an MS-DOS one.
For example:
gfind . -iname *.pdf -ls
A little wordy, but this link describes the issue. The short answer is that only double-quotes actually perform quoting in Windows' cmd.exe or command.exe.
Also, bear in mind that Windows expands *.pdf in the local directory first -- see Gnuwin32 find.exe expands wildcard before performing search.
I think the key to your issue is explained here
https://stackoverflow.com/a/3996353/8543838
Does not answer your question, but in the past I too had a few issues with GnuWin32 ‘find’ and I just wanted to let you know there is an alternative, part of ezwinports (another port of gnu tools).
I also seem to remember that ezwinports’s find was much faster than GnuWin32’s.
Also, my trick to avoid renaming Gnu tools that are the same as CMD’s built in functions (such as mkdir, echo and find) is to use ‘which find’ for example in a script. Then you know you are using gnu find and don’t need to touch anything.
Related
Note: There are several similar questions, which I have seen and read. None of them are the precise problem I'm having, and none of their answers work for me.
I have installed several Python versions (Python 2.7, 3.8, 3.9, and 3.10) on my macOS Ventura system using Pyenv. The installed directories include a python-config file in /bin and an /include directory with many header files, so I do not need to install python-devel or similar:
$ ls -al /Users/williamsn/.pyenv/versions/3.10.9/bin/*-config
lrwxr-xr-x 1 williamsn staff 17 Dec 19 17:24
/Users/williamsn/.pyenv/versions/3.10.9/bin/python-config -> python3.10-config
lrwxr-xr-x 1 williamsn staff 17 Dec 19 17:24
/Users/williamsn/.pyenv/versions/3.10.9/bin/python3-config -> python3.10-config
-rwxr-xr-x 1 williamsn staff 2073 Dec 19 17:24
/Users/williamsn/.pyenv/versions/3.10.9/bin/python3.10-config
$ ls -al /Users/williamsn/.pyenv/versions/3.10.9/include/python3.10/
total 1192
drwxr-xr-x 86 williamsn staff 2752 Dec 19 17:24 .
drwxr-xr-x 3 williamsn staff 96 Dec 19 17:24 ..
-rw-r--r-- 1 williamsn staff 3224 Dec 19 17:24 Python.h
...
-rw-r--r-- 1 williamsn staff 3026 Dec 19 17:24 import.h
...
-rw-r--r-- 1 williamsn staff 48878 Dec 19 17:24 pyconfig.h
...
-rw-r--r-- 1 williamsn staff 2863 Dec 19 17:24 weakrefobject.h
As a best practice, I work exclusively in virtualenvs to keep the base Python installation clean and pristine. I create my virtualenvs using the venv module built in to Python 3:
$ python3.10 -m venv my_venv
After doing so, there are two problems:
The my_venv/include directory is empty (does not contain the python3.10 directory or any of the header files from the parent Python and does not symlink to the parent Python)
There is no python-config / python3-config / python3.10-config in my_venv/bin.
So, for things requiring the Python headers:
If it tries to find the headers using python-config (which many projects do), it will fail.
If it tries to find the headers using the Python prefix and adding /include to it (which many projects do, notably Boost), it will fail.
If it tries to find the headers by importing sysconfig and calling sysconfig.get_paths(), it will succeed, albeit with paths outside the virtualenv.
Now, on a case-by-case basis, I can work around this, and already have. I can manually copy over python_config and then either export CPATH to add /Users/williamsn/.pyenv/versions/3.10.9/include/python3.10 or modify the virtualenv to symlink to /Users/williamsn/.pyenv/versions/3.10.9/include. These work, but they don't seem right to me. I can't make a global workaround anywhere (such as exporting CPATH in my Bash profile), because I'm working with multiple Python versions, and I'd end up with the wrong headers half the time. It seems to me like a virtualenv that has an empty include directory and is missing python-config when its parent has a full include directory and contains python-config is a broken virtualenv.
Is there an option I'm missing to include these pieces? Is this a bug I need to file against Python/venv?
What is the difference between two commands, pls help to explain it.
ps -ef|sort +6|tail
oracle 55676 1 0 03:06:16 - 0:36 oracleprod (LOCAL=NO)
oracle 24876 1 0 02:52:56 - 0:40 oracleprod (LOCAL=NO)
oracle 41616 1 0 07:00:59 - 0:44 oracleprod (LOCAL=NO)
oracle 43460 1 0 02:45:05 - 0:53 oracleprod (LOCAL=NO)
oracle 25754 1 0 08:10:03 - 1:01 oracleprod (LOCAL=NO)
ps -ef|sort +5|tail
root 5440 2094 0 Nov 21 - 0:47 /usr/sbin/syslogd
root 9244 1 0 Nov 21 - 3:26 ./pcimapsvr.ip -D0
root 10782 1 0 Nov 21 - 4:41 ./pciconsvr.ip -D0
Why do both commands show different processes ? And if I keep on changing the value of 'sort +3' or reduce, the processes keeps on changing. What exactly is command all about ? Please help to explain.
You are sorting the wrong columns using both an obsolete syntax and a wrong method. No surprise random processes show up.
You'll get the top consumers that way:
ps -ef | sort -n -k8 | tail
-n means sort numerically
-k8 means sort the the eight column (cumulative execution time)
I am using find-name-dired to find multiple instances of files that all have the same name (call it foo.txt) but in different directories. I want the files listed by alphabetical order of file path. However, they're listed in what looks like a random order. Neither dired-sort-menu nor dired-sort-chiesa will sort the output of find-name-dired, even though it will work on other dired buffers (whose format looks very similar). If I write the contents of the dired buffer to a file, I'm able to open a shell and submit the file to a sort command in the shell that uses the 9th field (the path) as a key. This produces output that looks right, but of course it's no longer a dired buffer.
Is there a way that I can
read in that externally sorted file and open it in dired "mode" (analogous to compilation mode),
sort the output of find-name-dired while still in dired mode, or
produce output from find-name-dired that's sorted the way I want from the beginning?
UPDATE:
Just to make things a bit more concrete, here's the current buffer:
/home/afrankel/Documents/emacs_test/:
find . \( -iname foo.txt \) -exec ls -ld \{\} \;
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 a/foo.txt
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 b/foo.txt
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 d/foo.txt
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 c/z/foo.txt
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 c/foo.txt
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 f/foo.txt
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 e/foo.txt
find finished at Fri Nov 30 17:00:41
Pressing "s" (which would sort most dired buffers) gives the error "Cannot sort this dired buffer".
I want the buffer to look like this:
/home/afrankel/Documents/emacs_test/:
find . \( -iname foo.txt \) -exec ls -ld \{\} \;
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 a/foo.txt
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 b/foo.txt
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 c/foo.txt
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 c/z/foo.txt
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 d/foo.txt
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 e/foo.txt
-rw-r--r-- 1 afrankel users 4 Nov 30 16:59 f/foo.txt
find finished at Fri Nov 30 17:00:41
When you type s in a "normal" Dired buffer, Dired doesn't actually sort the buffer. What it does is to change the value of dired-actual-switches so that it does (or doesn't) contain the -t option ("sort by modification time") and then call revert-buffer which re-runs ls with the new options. This obviously doesn't work in a Dired buffer produced by running find.
What you need to do instead is to arrange to run find with the -s option:
-s Cause find to traverse the file hierarchies in lexicographical
order, i.e., alphabetical order within each directory.
which you can do (for all find-dired commands) by evaluating
(setq find-program "find -s")
Okay, I figured out how to do it using defadvice to automatically change the value of find-ls-option while I'm executing my new wrapper function (find-name-dired-sorted) and then to change it back to its original value.
(defadvice find-name-dired (around find-name-dired-around)
"Advice: Sort output by path name."
(let ((find-ls-option (list "-exec ls -ld {} \\; |sort --key=9")))
ad-do-it))
(defun find-name-dired-sorted (dir pattern)
"Sort the output of find-name-dired by path name."
(interactive
"DFind-name (directory): \nsFind-name (filename wildcard): ")
(ad-activate 'find-name-dired)
(find-name-dired dir pattern)
(ad-deactivate 'find-name-dired))
Here's one way to do it manually via a temporary change to the configuration:
Run M-x customize-group find-dired.
Change the contents of the field "Find Ls Option" . It should initially read "-exec ls -ld {} \;". Append text to make it read "-exec ls -ld {} \; |sort --key=9". (In other words, sort by field 9, which is the full path treated as a single string.)
Set the option for the current session only.
UPDATE: It's better to do use defadvice, as I did in my other (later) answer.
I'm simply trying to get a list of filenames given a path with wildcard.
my $path = "/foo/bar/*/*.txt";
my #file_list = glob($path);
foreach $current_file (#file_list) {
print "\n- $current_file";
}
Mostly this works perfectly, but if there's a file greater than 2GB, somewhere in one of the /foo/bar/* subpaths, the glob returns an empty array without any error or warning.
If I remove the file file or add a character/bracket sequence like this:
my $path = "/foo/bar/*[0-9]/*.txt";
or
my $path = "/foo/bar/*1/*.txt";
then the glob works again.
UPDATE:
Here's an example (for a matter of business policy I had to mask the pathname):
[root]/foo/bar # ls -lrt
drwxr-xr-x 2 root system 256 Oct 11 2006 lost+found
drwxr-xr-x 2 root system 256 Dec 27 2007 abc***
drwxr-xr-x 2 root system 256 Nov 12 15:32 cde***
-rw-r--r-- 1 root system 2734193149 Nov 15 05:07 archive1.tar.gz
-rw-r--r-- 1 root system 6913743 Nov 16 05:05 archive2.tar.gz
drwxr-xr-x 2 root system 256 Nov 16 10:00 fgh***
[root]/foo/bar # /home/user/test.pl
[root]/foo/bar #
Removing the >2GB file (or globbing with "/foo/bar/[acf]/" istead of "/foo/bar//")
[root]/foo/bar # ls -lrt
drwxr-xr-x 2 root system 256 Oct 11 2006 lost+found
drwxr-xr-x 2 root system 256 Dec 27 2007 abc***
drwxr-xr-x 2 root system 256 Nov 12 15:32 cde***
-rw-r--r-- 1 root system 6913743 Nov 16 05:05 archive2.tar.gz
drwxr-xr-x 2 root system 256 Nov 16 10:00 fgh***
[root]/foo/bar # /home/user/test.pl
- /foo/bar/abc***/heapdump.phd.gz
- /foo/bar/cde***/javacore.txt.gz
- /foo/bar/fgh***/stuff.txt
[root]/foo/bar #
Any suggestion?
I'm working with:
Perl 5.8.8
Aix 5.3
The filesystem is a local jfs.
In the absence of a proper answer you're going to want a work-around. I'm guessing you've hit some platform-specific bug in the glob() implementation of 5.8.8
I had a quick look at the source on CPAN but my C is too rusty to spot anything useful.
There have been lots of changes to that module though, so a bug may well have been reported and fixed. You're not even on the last release of 5.8 - there's a 5.8.9 out there which mentions updates to AIX compatibility and File::Glob.
I'd test this by installing local::lib if you haven't already and then perhaps cpanm and try updating File::Glob - see what that does. You might need to download the files by hand from e.g. here
If that solves the problem then you can either deploy updates to the required systems, or you'll have to re-implement the bits of glob() you want. Which is going to depend on how complex your patterns get.
If it doesn't solve the problem then at least you'll be able to stick some printf's into the code and see what it's doing.
Hopefully someone will post a real answer and make this redundant about 5 minutes after I click "Post Your Answer" though.
I've never used the new Glob function before, so i cant comment on benefits/problems, but it seems quite a lot of people have had issues using it: see => https://stackoverflow.com/search?q=perl+glob&submit=search for some questions and possible solutions.
IF you don't mind trying out something else:
Here is my tried and tested 'old school' perl solution i have used in countless projects:
my $path = "/foo/bar/";
my #result_array = qx(find $path -iname '*.txt'); #run the system find command
If you - for whatever reason prefer not to run a system command from within your script, then lookup the built in Find::Perl Module instead: http://search.cpan.org/~dom/perl-5.12.5/lib/File/Find.pm
good luck
For example, if I have two files:
file1:
This is file 1
and file2:
This is file 2
and create patch with the following command:
diff -u file1 file2 > files.patch
result is:
--- file1 Fri Aug 13 17:53:28 2010
+++ file2 Fri Aug 13 17:53:38 2010
## -1,1 +1,1 ##
-This is file 1
+This is file 2
Then if I try to apply this patch on Solaris with patch command:
patch -u -i files.patch
it hangs on:
Looks like a unified context diff.
File to patch:
1. Is there a way to use Solaris native patch command with unified diffs?
2. Which diff format is considered most portable if it's not possible to apply unified format?
Update:
I've found answer on the first part of my question. Seems that patch on Solaris hangs if the second file (file2 in this case) exists in the same folder as the first one (file1). For example, the following quite common diff:
--- a/src/file.src Sat Aug 14 23:07:29 2010
+++ b/src/file.src Sat Aug 14 23:07:37 2010
## -1,2 +1,1 ##
-1
-
+2
will not work with quite common patch command:
patch -p1 -u -d a < file.patch
while the following diff (note second file is renamed):
--- a/src/file.src Sat Aug 14 23:07:29 2010
+++ b/src/file_new.src Sat Aug 14 23:07:37 2010
## -1,2 +1,1 ##
-1
-
+2
will work perfectly.
For the second part of my question see accepted answer below.
On Solaris /usr/bin/patch is an old version required to comply with some ancient standards.
A modern version of GNU patch is provided as /usr/bin/gpatch on Solaris 8 and later.
diff -cr old.new new.txt > patch.txt
gpatch -p0 < patch.txt
Works perfectly for me (using gpatch)
Single Unix v2 and v3 both support context diffs but not unified diffs, so for better portability you should use context diffs (-c option to diff and patch).
On older Solaris releases (pre-10, I think), you need to make sure that /usr/xpg4/bin is before /usr/bin in your $PATH, otherwise you may get compatibility versions of some utilities instead of standard ones.