How can I use VS Code's Convert Indentation To Spaces or Convert Indentation to Tabs commands on all the files in my workspace in a single action instead of using the command for each file?
I'm not aware of a way to do this with VS Code (at least- not without extensions, and I don't know of any such extensions offhand).
But if you're on a posix system (not sure if I'm using "posix" right here), you can do this via command line using a modified version of this:
git ls-files | command grep -E '*.ts$' | awk '{print "expand --tabs=4 --first-only", $0, " > /tmp/e; mv /tmp/e ", $0}' | sh
The above command lists all files tracked in the git repo for the current working directory, filters for files with the .ts extension, and then uses awk and expand to replace leading indentation of a tabs to a specified number of spaces.
To go from spaces to tabs, use the unexpand command instead.
If you're not working with a git repo, you can replace git ls-files with find -type f (the advantage of git ls-files is that it won't touch anything that's not tracked).
Just change the regular expression in the grep filter to whatever you need.
The command replaces leading groups of 4 spaces with tab characters. Just change the --tabs argument to the unexpand command with whatever number of spaces your indentation is.
Related
I'm very very very new to programming and trying to learn how to make tedious analysis tasks a little faster. I have a master folder (Master) with 50 experiment folders and within each experiment folder are another set of folders holding text files. I want to extract 2 lines from one of the text fiels (experiment title on line 7, slope on line 104) and copy them to a new single file.
So far, all I have learned is how to extract the lines and add to a new file.
sed -n '7p; 104 p' reco.txt >> results.txt
How can I extract these two lines from all files 'reco.txt' in the subfolder of the folder 'Master' and export into a single text file?
As much explanation as you can bear would be great to help me learn.
You can use find in combination with xargs for this. On its own, you can get a list of all relevant files:
find . -name reco.txt -print
This finds all files named reco.txt in the current directory (.) or any subdirectories and writes them to standard output.
Now, normally you can use the -exec argument to find, which will run a program for each file found, except that typically multiple results are combined into a single execution (appended to the command line). Your particular invocation of sed only works on one file at a time.
So, instead of -exec, you can use xargs which is essentially the same thing but with more control.
find Master -name reco.txt -print0 | xargs -0 -n1 sed -n '7p; 104 p' > results.txt
This does the following:
Searches in the directory Master or subdirectories for any file named reco.txt.
Outputs each filename with null-terminator instead of newline (-print0) -- this allows the full path to contain characters that usually need escaping (such as spaces)
Pipes the result into xargs, which does the following:
Accepts null-terminated strings (-0)
Only puts at most one file into each command (-n1)
Runs sed -n '7p; 104 p' on that file
Entire output is redirected to results.txt, which will overwrite any existing contents in the file.
Whenever i push through git all my bash scripts seem to be corrupted with the \r character. It doesn't affect the code, but it just adds a significant amount of noise to my work. Looked all over the web, but can't seem to find a solution.
Example:
echo "*************************************************************************"\r
^
Every line in my bash scripts are always ended with this special character. I use STS on Windows 7. Any ideas?
Put this two lines into your .gitconfig file in the root of your repo or into your home if you need to make this settings global :
[core]
eol = lf
You can find more about this here : https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
I have been trying to do a recursive grep command on files in sub folders using grep in NTemacs and Cygwin. So far the "best" results have been using grep in eshell. When I use this:
grep "t" -r *
I get a list of all file names containing the letter t, in all sub folders one layer down but notthing else. In Cygwin i get nothing. I'm working on a directroy that is not in the Cygwin install. Don't know if that mather or not.
What I want is to match the content of a more complex string in all files (and not just the file names, but the content). And in all sub directories.
I would like to use eshell from emacs but I'm open to suggestions, apart form using LINUX. This is a work PC and I don't want to do all the setup of a LINUX install.
i just wrote a very similar answer to another question, but i suspect it's the same root problem:
my first thought is that your files have windows line endings (CRLF) as opposed to unix/linux line endings (LF), and that is messing with grep's ability to parse the file. try running this:
dos2unix filename
on each file you need to search then try your grep statement again.
if you need to convert many files across several directories, i suggest using dos2unix with the -exec action of find:
find . -exec dos2unix {} \;
(add whatever other options you need to find before running that, of course)
How can I search the command history in cygwin?
I don't want to keep pressing the arrow keys to execute a command from console command history.
If you are using the default editing mode, do ctrl+R to search back through your history.
If you have done set -o vi to use vi editing mode, then it is esc-/
The history command is the way to go. I use
h ()
{
history | cut -f 2- | sort -u | grep -P --color=auto -e "$*"
}
so that I can type something like h git.*MyProgram, h ^tar -c, h svn:ignore, etc to pull up a sorted list of past commands matching a regex.
You might also want to add the following lines to ~/.inputrc:
# Ctrl+Up/Down for searching command history
"\e[1;5A": history-search-backward
"\e[1;5B": history-search-forward
With these in place, you can type a partial command prefix (such as gi or sql) then use Ctrl+Up to scroll back through the list of just your command history entries that match that prefix (such as git clone https://code.google.com/p/double-conversion/ and sqlite3 .svn/wc.db .tables). This can be a lot faster than searching and then cutting and pasting if you want to edit or re-execute a command that was fairly recent.
I use the history command in combination with grep, e.g. history | grep vi shows all commands where vi was used.
Checkout the "Gnu Bash Manual" (man bash) for the command "fc". E.g.fc -l -80 would list the last 80 commands, while other options let you search with RegEx...
Do
vi ~/.inputrc
Add
For arrow up/down bindings:
"\e[A": history-search-backward
"\e[B": history-search-forward
Or for page up/down bindings:
"\e[5~": history-search-backward
"\e[6~": history-search-forward
Close and open cygwin.
Voila.
I think one of the easiest way is to pipeline it with less and press search character ("/") and then type the command you wanna find.
history | less
and then
/text to find
to find the desired command
Another way
is to append the stdout form history command to a file: history > /cygdrive/path/file.txt
and then search in the document.
is there a command line program that gives recursive word-based diff (on 2 directories)?
diff -u is recursive, but it doesn't do word by word comparison. wdiff and dwdiff does word based diff but there are not built-in options for recursive diff.
I would like to pipe the result to colordiff so a program that generates output that colordiff understands would be especially useful. Any suggestions? Thanks!
CC
Git can do it and output color:
The following often works:
git diff --color-words path1 path2
but in general you may need to do
git diff --no-index --color-words path1 path2
Neither file even needs to be in a git repository!
--no-index is needed if you and the paths are in a git working tree. It can be elided if you or one of the files are outside a git working tree.
Manpage: https://git-scm.com/docs/git-diff/1.8.5 (and later...)
git diff --no-index [--options] [--] […]
This form is to compare the given two paths on the filesystem. You can
omit the --no-index option when running the command in a working tree
controlled by Git and at least one of the paths points outside the
working tree, or when running the command outside a working tree
controlled by Git.