I have several folders of video files where, due to the download manager I use, they are all named in the following format "FILENAME.mp4; filename= FILENAME.mp4" All I've been trying to do is to remove everything after (and including) ".mp4; filename". However, I haven't found a way to do this.
I have tried some free software (such as Renamer, Namechanger, Name Munger for Mac, Transnomino) but I failed to do what I need to.
I'm working on Mac OSX 10.13.6.
Any help with this issue would be appreciated.
You can achieve it using Terminal. Go to the folder where you want to rename files using this cd command, for example:
cd ~/Documents/Videos
And run this command to rename all files recursively:
find . -iname "*.mp4;*" | sed -E 's/(\.[^\.]*)(\.mp4)(.*)/mv "\1\2\3" "\1\2"/' | sh
This command will keep only FILENAME.mp4 part from FILENAME.mp4; filename= FILENAME.mp4 file name
I used to extensively use a windows Rename tool called Renamer 6.0, and it had a "pattern rename" facility called "Multi change" that could have handled this.
In the context of that tool it would be asking for a source pattern like %a= %b and a destination pattern (like %b), everything after the = would be stored in %b variable and then renaming the file to just %b would lose everything after the =
See if your preferred rename tool has a similar facility?
If your tool supports regex, then find: .*?=(.*) and replace with $1
I'm also minded that asking this question on https://unix.stackexchange.com/ might elicit some help crafting a shell script that will perform this rename (though also plenty of shell capable people here, one of them may see it - it's just that it's not quite as hardcore programmer-y a question as most).
If you're willing to learn/use java, then that could be another good way to get the problem solved. It would (at a guess) look something like this:
for (final File f : new File("C:\\temp").listFiles()) {
if (f.isFile()) {
string n = f.getName();
if (n.contains("=")) {
f.renameTo(new File(n.substring(n.indexOf("=")+1));
}
}
}
(OS is Windows 7 Professional. jq is version 1.5.)
I've been using jq to automate prettifying some JSON files (with Python). It seems to me after some time trying to determine why it wasn't working that jq fails silently when working with a file path string that's length 28, or simply stops working if the file path string is length 29 or more.
E.g. on cmd (and it's worth pointing out that I made a kind of shortcut so that jq calls jq-win64.exe, and tested the latter directly as well, so that's not the source of the issue):
C:\jq>jq . 123456789012345678901234567
displays prettified content of the file;
C:\jq>jq . 1234567890123456789012345678
displays nothing; and
C:\jq>jq . 12345678901234567890123456789
causes a "jq-win64.exe has stopped working" window.
(I also tested this on JSON files within folders; the common point was that the input string be of length 28 or more including slashes to fail.)
Is this a bug? If it's not, what can I do to work around it Okay, I admit that was a stupid question, I can work around it by copying content into a temp file in the base folder, prettify it, and then save it back to wherever I want it to be. More on-point question: is this the best workaround available for me to take?
There was a Windows-specific bug in jq 1.5 (see e.g. https://github.com/stedolan/jq/issues/1094). It was fixed shortly after the release of jq 1.5.
To obtain a post-1.5 .exe for Windows, see any of:
https://chocolatey.org/packages?q=jq
https://stedolan.github.io/jq/download
https://github.com/stedolan/jq/wiki/Installation#windows-using-appveyor
CLISP's interface to PARI is configured with the configure.in containing AC_LIB_LINKFLAGS([pari]) from lib-link.m4.
The build process also requires the Makefile to know where the datadir of PARI is located. To this end, Makefile.in has
prefix = #LIBPARI_PREFIX#
DATADIR = #datadir#
and expects to find $(DATADIR)/pari/pari.desc (normally
/usr/share/pari/pari.desc or /usr/local/share/pari/pari.desc).
This seems to work on Mac OS X where PARI is installed by homebrew in /usr/local (and LIBPARI_PREFIX=/usr/local), but not on Ubuntu, where PARI is in /usr, and LIBPARI_PREFIX is empty.
How do I insert the location of the PARI's datadir into the Makefile?
PS. I also asked this on the autoconf mailing list.
PPS. In response to #BrunoHaible's suggestion, here is the meager attempt at debugging on Linux (where LIBPARI_PREFIX is empty).
$ bash -x configure 2>&1 | grep found_dir
+ found_dir=
+ eval ac_val=$found_dir
+ eval ac_val=$found_dir
You are trying to use $(prefix) in an unintended way. In an Autotools-based build system, the $(prefix) represents a prefix to the target installation location of the software you're building. By setting it in your Makefile.in, you are overriding the prefix that configure will try to assign. However, since you appear not to have any installation targets anyway, at least at that level, that's probably more an issue of poor form than a cause for malfunction.
How do I insert the location of the PARI's datadir into the Makefile?
I'd recommend computing or discovering the needed directory in your configure script, and exporting it to the generated Makefile via its own output variable. Let's take the second part first, since it's simple. In configure.in, having in some manner located the wanted data directory and assigned it to a variable
DATADIR=...
, you would make an output variable of that via the AC_SUBST macro:
AC_SUBST([DATADIR])
Since you are using only Autoconf, not Automake, you would then manually receive that into your Makefile by changing the assignment in your Makefile.in:
DATDIR = #DATADIR#
Now, as for locating the data directory in the first place, you have to know what you're trying to implement before you can implement it. From your question and followup comments, it seems to me that you want this:
Use a data directory explicitly specified by the user if there is one. Otherwise,
look for a data directory relative to the location of the shared library. If it's not found there then
(optional) look under the prefix specified to configure, or specifically in the specified datadir (both of which may come from the top-level configure). Finally, if it still has not been found then
look in some standard locations.
To create a configure option by which the user can specify a custom data directory, you would probably use the AC_ARG_WITH macro, maybe like this:
AC_ARG_WITH([pari-datadir], [AS_HELP_STRING([--with-pari-datadir],
[explicitly specifies the PARI data directory])],
[], [with_pari_datadir=''])
Thanks to #BrunoHaible, we see that although the Gnulib manual does not document it, the macro's internal documentation specifies that if AC_LIB_LINKFLAGS locates libpari then it will set LIBPARI_PREFIX to the library directory prefix. You find that that does work when the --with-libpari option is used to give it an alternative location to search, so I suggest working with that. You certainly can try to debug AC_LIB_LINKFLAGS to make it set LIBPARI_PREFIX in all cases in which the lib is found, but if you don't want to go to that effort then you can work around it (see below).
Although the default or specified installation prefix is accessible in configure as $prefix, I would suggest instead going to the specified $datadir. That is slightly tricky, however, because by default it refers to the prefix indirectly. Thus, you might do this:
eval "datadir_expanded=${datadir}"
Finally, you might hardcode a set of prefixes such as /usr and /usr/local.
Following on from all the foregoing, then, your configure.in might do something like this:
DATADIR=
for d in \
${with_pari_datadir} \
${LIBPARI_PREFIX:+${LIBPARI_PREFIX}/share/pari} \
${datadir_expanded}/pari \
/usr/local/share/pari \
/usr/share/pari
do
AS_IF([test -r "$[]d/pari.desc"], [DATADIR="$[]d"; break])
done
AS_IF([test x = "x$DATADIR"], [AC_MSG_ERROR(["Could not identify PARI data directory"])])
AC_SUBST([DATADIR])
Instead of guessing the location of datadir, why don't you ask PARI/GP where its datadir is located? Namely,
$ echo "default(datadir)" | gp -qf
"/usr/share/pari"
does the trick.
I'm having trouble installing Homebrew, and it looks like the problem (invalid byte sequence in UTF-8 (ArgumentError) error message) is due to a fault in my PATH. when I run echo $PATH, I get the following (be sure to scroll to the far right in the code block below to see the fault):
/usr/local/mysql/bin:/opt/subversion/bin/:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:PATH=/usr/local/share/python:$PATH:PATH=/usr/local/share/npm/bin:$PATH:export PATH��:/usr/local/git/bin
I have no idea where those strange characters just before the /usr/local/git/bin path are coming from. I'm using bash (tried zshell, same problem). I can't find where this coming from. my .bash_profile file looks clean, too.
Examine your ~/.profile, ~/.bash_profile, and ~/.bashrc files. It is also possible that these values are being set in /etc/profile or other system-wide files, but the nature of the errors is such that I would assume they are the result of your own manual edits of your personal files. You're the best judge to decide what you may have changed and when.
Look for entries such as the following:
PATH='/usr/local/share/python:$PATH'
PATH='PATH=/usr/local/share/npm/bin:$PATH'
PATH='export PATH��:/usr/local/git/bin'
They should instead look like
PATH=/usr/local/share/python:$PATH
PATH=/usr/local/share/npm/bin:$PATH
PATH=$PATH:/usr/local/git/bin
# Not strictly necessary -- PATH is already exported
export PATH
See a pattern? These all add a value to PATH by setting it to prefix:$PATH or $PATH:suffix where the new prefix or suffix is the directory where you have installed a local package. Whether the new value should be a prefix or a suffix is probably of little consequence -- except if you are trying to override a system version (say, your /usr/local/git is installed because /usr/bin/git is too old -- then, it's important that your local version comes first in the PATH). There is also a minuscule speed difference the first time you run a command; the shell has to look in more places before finding it if it's at the end of the PATH.
The difference in quoting is significant -- PATH=$PATH:suffix expands to the old value of PATH with :suffix added on, whereas PATH='$PATH:suffix' replaces the old value of PATH with the literal string $PATH with :suffix added on. You're lucky none of this has ended up replacing your original PATH completely, which would render your shell by and large inoperable (at least until you discover that you have to use /bin/ls instead of just ls).
Is there a similar utility to grep available from the Windows Command Prompt, or is there a third party tool for it?
There is a command-line tool called FINDSTR that comes with all Windows NT-class operating systems (type FINDSTR /? into a Command Prompt window for more information) It doesn't support everything grep does but it might be sufficient for your needs.
PowerShell (included as standard on Windows 7/2008R2, optional for XP/2003/Vista/2008) which includes the select-string cmdlet for this purpose.
Grep for Windows by GnuWin Project (2014-10-02: It's outdated, see comments below)
as mentioned, findstr works fine. example :
C:>dir | findstr Windows
11/06/2013 09:55 PM Windows
I'm surprised no one has mentioned FINDSTR. I'm no grep poweruser, but findstr does what I need it to, filter files and stdin, with some primitive regex support. Ships with Windows and all that. (Edit: Well someone did mention findstr, It's late I guess)
Cygwin grep and more ;)
I also found one more way of utilizing GREP like functionality in Windows 7 and above without any extra application to install and on older systems you can use install Powershell.
In Powershell, User can use Where-Object it has quite comprehensive set of feature that provides all the functionality of GREP plus more.
Hope It helps.
GnuWin32 is worth mentioning, it provides native Win32 version of all standard linux tools, including grep, file, sed, groff, indent, etc.
And it's constantly updated when new versions of these tools are released.
On Windows I use Far Manager for file search. BSD licensed, works in console, saves time on typing cmdline parameters. Here is its search dialog invoked by Alt-F7.
UnxUtils is a great set of Unix utilites that run on Windows. It has grep, sed, gawk, etc.
An excellent and very fast file search utility, Agent Ransack, supports regular expression searching. It's primarily a GUI utility, but a command-line interface is also available.
Update: This wasn't true when the question was originally asked, but now Microsoft lets one Install the Windows Subsystem for Linux, and Windows will then run grep. In PowerShell, run:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
In the windows reskit there is a utility called "qgrep". You may have it on your box already. ;-) It also comes with the "tail" command, thank god!
You have obviously gotten a lot of different recommendations.
My personal choice for a Free, 3rd Party Utility is: Agent Ransack
Agent Ransack Download
Despite its somewhat confusing name, it works well and can be used in a variety of ways to find files.
Good Luck
the all-in-one busybox contains grep / egrep / sed / awk and MANY more
get it from:
http://frippery.org/busybox/index.html
http://frippery.org/files/busybox/?C=M;O=D
Update: no longer available - or some older
https://github.com/pclouds/busybox-w32
Although not technically grep nor command line, both Microsoft Visual Studio and Notepad++ have a very good Find in Files feature with full regular expression support. I find myself using them frequently even though I also have the CygWin version of grep available on the command line.
I'll add my $0.02 to this thread. dnGREP is a great open source grep tool for windows that supports undo, windows explorer integration, search inside PDFs, zips, DOCs and bunch of other stuff...
Yes there is only one program for Windows PC which have solid GUI and it is essential util for me. I work as a developer and on every computer I've had, first thing install XFind program. It is created in 1997 and till now version is 1.0 and till now works and it is the best. Frequently I need to search some string in a ".cs", ".aspx", ".sct" (Visual FoxPro form code file) or just ".*" and XFind scans all files and show me files and another great thing is that you can look where string is in the file. XFind has also some kind of editor. If it binary file it will show you string finded. Try it and use it forever if you are developer like me.
I realize its an old question but I came across this post seeking an answer. And I have found one so adding it here for the collective internet memory
Powershell: Select-String
Module:
Microsoft.PowerShell.Utility
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/select-string
and an informative blog post with advanced examnples: "How to “grep” in PowerShell"
https://antjanus.com/blog/web-development-tutorials/how-to-grep-in-powershell/
A simple example from that blog post:
cat package.json | Select-String -Pattern webpack
ls ./src/components/ | Select-String -Pattern View
C:> cat post.md | Select-String -Pattern "^\w*:"
Bare Grep is nice if you want a GUI. Gnu grep is good for CLI
If you don't mind a paid-for product, PowerGREP is my personal favorite.
We have recently used PowerGREP for some fairly advanced bulk operations on thousands of files. Including regex searching in content of PDF files, and altering PDF documents in largescale.
Its worth the money if you want to save time from manuel labour. You can try it before you buy i think.
If you have to use bare Windows, then in addition to the Powershell option noted above, you can use VBScript, which has decent RegEx support.
MS also has a decent scripting area on Technet with a ton of examples for administrators.
Just try LikeGrep java utility.
It may help you in very many cases.
As you wish, it can also replace some text, found in files.
It garantees its work on large files (up-to 8 Gb tested)
As mentioned above, the gnuwin32 project has a Windows CLI version of grep.
If you want something with a graphical interface, I would recommend the (open-source) tool AstroGrep.
It has been a while since I've used them, but Borland (Embarcadero now) included a command line grep with their C/C++ compiler. For some time, they have made available their 5.5 version as a free download after registering.
There's a commercial grep utility available from Oak Road Systems.
I recommend PowerGrep
I had to do an e-discovery project several years ago. I found that fisdstr had some limitations, most especially fisdstr would eventually fail
the script had to search across thousands of files using a couple of dozen search terms/phrases.
Cygwin's grep worked much better, it didn't choke often, but ultimately I went to PowerGrep because the graphical interface made it much easier to tell when and where it crashed, and also it was really easy to edit in all the conditionals and output that I wanted. Ultimately PowerGrep was the most reliable of the three.
I know that it's a bit old topic but, here is another thing you can do. I work on a developer VM with no internet access and quite limited free disk space, so I made use of the java installed on it.
Compile small java program that prints regex matches to the console. Put the jar somewhere on your system, create a batch to execute it and add the folder to your PATH variable:
JGrep.java:
package com.jgrep;
import java.io.BufferedReader;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class JGrep {
public static void main(String[] args) throws FileNotFoundException, IOException {
int printGroup = -1;
if (args.length < 2) {
System.out.println("Invalid arguments. Usage:");
System.out.println("jgrep [...-MODIFIERS] [PATTERN] [FILENAME]");
System.out.println("Available modifiers:");
System.out.println(" -printGroup - will print the given group only instead of the whole match. Eg: -printGroup=1");
System.out.println("Current arguments:");
for (int i = 0; i < args.length; i++) {
System.out.println("args[" + i + "]=" + args[i]);
}
return;
}
Pattern pattern = null;
String filename = args[args.length - 1];
String patternArg = args[args.length - 2];
pattern = Pattern.compile(patternArg);
int argCount = 2;
while (args.length - argCount - 1 >= 0) {
String arg = args[args.length - argCount - 1];
argCount++;
if (arg.startsWith("-printGroup=")) {
printGroup = Integer.parseInt(arg.substring("-printGroup=".length()));
}
}
StringBuilder sb = new StringBuilder();
try (BufferedReader br = new BufferedReader(new FileReader(filename))) {
sb = new StringBuilder();
String line = br.readLine();
while (line != null) {
sb.append(line);
sb.append(System.lineSeparator());
line = br.readLine();
}
}
Matcher matcher = pattern.matcher(sb.toString());
int matchesCount = 0;
while (matcher.find()) {
if (printGroup > 0) {
System.out.println(matcher.group(printGroup));
} else {
System.out.println(matcher.group());
}
matchesCount++;
}
System.out.println("----------------------------------------");
System.out.println("File: " + filename);
System.out.println("Pattern: " + pattern.pattern());
System.out.println("PrintGroup: " + printGroup);
System.out.println("Matches: " + matchesCount);
}
}
c:\jgrep\jgrep.bat (together with jgrep.jar):
#echo off
java -cp c:\jgrep\jgrep.jar com.jgrep.JGrep %*
and add c:\jgrep in the end of the PATH environment variable.
Now simply call jgrep "expression" file.txt from anywhere.
I needed to print some specific groups from my expression so I added a modifier and call it like jgrep -printGroup=1 "expression" file.txt.
Use Cygwin...
it has 32 and 64 bits versions
and it works fine from Windows 2000 (*)
to Windows 10 or Server 2019
I use Cygwin for a long time...
and recently tryed to substitute with Windows-Linux-Subsystems...
not for long...
I quickly went back to Cygwin again...
much more flexible, controlable and rich...
also less intrusive...
just add \bin to the path...
and you can use it anyware in Windows/Batch/Powershell...
or in a DOS-Box... or in a Powershell-Box...
Also you can install a ton of great packages
that really work... like nginX or PHP...
I even use the Cygwin PHP package in my IIS...
As a bonus wou can also use it from a bash shell...
(I think this was the original intent ;-))