weird behavior when deleting a chrome file - bash

I got this problem in which I sometimes have to delete a certain file before I can acces google-chrome. So for a quick fix I tried to make a bash file to delete it:
#!/bin/bash
rm -r /home/NAME_OF_USER/.config/google-chrome/SingletonLock
but everytime I want to open google-chrome after executing this little bash program, I have to open the path in the file explorer. Else I get the same error. The error says that this file should be deleted befor launch. Is there a way I can kind of "simulate" that I opened the path in the same bash program?

Kill the handlers of the file first:
lsof -t /home/NAME_OF_USER/.config/google-chrome/SingletonLock|xargs kill
From lsof manual:
-t This option specifies that lsof should produce terse output with process identifiers only and no header - e.g., so that the output
may be piped to kill(1).

Related

Cygwin execution of .sh file can't find grep command?

So I was trying to create little .sh script for my work and run into one little problem.
My cygwin terminal (x64) runs just fine and I'm using it often enough to do manual greps.
In the begging I had some issues with this command but now it works fine in cygwin terminal.
Once I wrote my little script and tried to run it only output I'm getting is "line 6: grep: command not found"
My execution method is:
Open cygwin terminal
cd to script location
type in ./script.sh
enter :)
Anyone knows how to fix that? I already added cygwin bin folder to my system path (Win 10 btw) but that didn't helped. Looked around for a while but haven't found anything useful, mostly issues with grep itself.
my script for reference:
mkdir -p output
PATH=$PWD"/output"
while IFS=";" read -r component location global
do
cd $location
grep -iRl $global --exclude-dir={wrongdir1,wrongdir2} > $PATH"/"$component".txt"
done < input.csv
you're overwriting you Cygwin system path: PATH=$PWD"/output" - instead of PATH use a diff var name.

Running gmt.script

I try to run a gmt-script and get the message:
bash-3.2$ plot_scenario.gmt
bash: plot_scenario.gmt: command not found
Does anyone know what could fix the problem?
I got a script from my supervisor, and it worked just fine on the uni Linux pc.
I have a Mac OS.
When you type text in shell, it tries to look for available commands. Here bash doesn't find any command like plot_scenario.gmt and outputs command not found.
The proper way to execute a file is ./filename where . refers to current directory. But you need to give execution permission to file you want to run. So, following commands may help you:
chmod +x <filename>
./<filename>
Note that make sure your pwd is where you're file is located. Another way to run or execute file is calling the shell:
bash /path/to/file

Ubuntu Shell Script Output Directory

I don't use bash much, but lately I've had to use it and I have been continuously running into an issue with command-line arguments, specifically output directories. Some example code below:
Running:
log2timeline -f win7 -z EST5EDT -r -p -o csv -w /home/sansforensics/Desktop/PATH/file /mnt/hgfs/DRIVE/INPUT
on the command line works exactly as expected, the -w flag signifies the output path/file and that is exactly where it ends up, on the user's desktop in the PATH folder.
But when I run it from a .sh file sitting on the Desktop of the same user, i.e.
sudo bash test.sh
and all the file contains is the same exact command, the output file does not show up in the expected location. What am I missing here??

Weird problem in running bash script

I wrote a bash script that fetches lyrics from a website. The script is here --> http://scrippets.wordpress.com/2011/02/01/fetching-lyrics-of-songs-from-the-terminal/ (the indentations in the script are correct unlike how it looks on the blog)
This script works perfectly well when executed from the terminal. Now i created a custom keyboard shortcut using compiz commands, that executes the following command when the right key combination is pressed :
gnome-terminal --working-directory="/home/tapan/sandbox/bash/" --window-with-profile=lyrics -e "/home/tapan/sandbox/bash/lyrics.sh" -t "`rhythmbox-client --print-playing`"
I created a new profile called "lyrics" to give the terminal that opens up a custom look. When i open up a terminal with this profile and run the script, it works perfectly fine again. However, when i use the keyboard shortcut to run the custom command, i get the following error:
Pink Floyd - Is There Anybody Out There?
wget: missing URL
Usage: wget [OPTION]... [URL]...
Try `wget --help' for more options.
cat: 3.txt: No such file or directory
I cannot figure out whats wrong. I mean if it works perfectly well in the terminal normally, why shouldn't this work? Any suggestions?
PS: The script i have written is pretty elementary and noobish, so any suggestions to improve it are also welcome in the comments :)
EDIT: The output has changed a little, now it just shows the name of the song playing and nothing else. Though sometimes it still shows the wget error.
EDIT2: When i run that gnome terminal command from a terminal, it works. The problem is only when running it with the keyboard shortcut using compiz commands or if i use the run dialog (the alt+f2 one).
The two wget commands should probably have the url variables in double quotes, for example: wget -q -U Mozilla -O 1.txt $link should be wget -q -U Mozilla -O 1.txt "$link"
You need to uriencode your song title so that special characters like '?', '&', '%', and '+' are not passed literally in your URL.
name3=${name2//\?/%3F}
searchq=${name3// /+}
will handle the ?'s. I don't know of a more general solution in bash without resorting to one-line Perl or Python scripts.

After doing grep and passing it to vim then quitting, why am I experiencing this weird console malfunctioning?

I tried this just now:
grep -RlI "id=\"kw\"" * | xargs vim
That gave me 16 results. It opened the first result in Vim. I made my very first edit and hit :q since I didn't know the shortcut to jump to the next file.
It threw me back to the console ( I am SSHed in to a server ). My console is messed up now. Anything I type I can't see, and anytime I hit enter it seems like it processes the command but the display/view is screwed up so
[meder#linode] is tabbed in on my console, at least halfway. reset does nothing since it seems to have messed up my real console.
Can anyone offer a solution that doesn't have this same downside? Or can anyone provide an explanation for why :qing out of the very first file messed up my console?
Background information: My PC is Debian Ubuntu, I am SSHed into a RHEL box. The files I opened were text/ascii files phtml/php files and not some weird binary files with crazy characters in them.
Here's a screenshot of what happened
EDIT #1: I just typed reset again and it seemed to work. The first reset did not work I think because somehow the console inserted some whitespaceish character inside it? Anyways, I would like an explanation for this weird behaviour.
Try:
vim -o `grep -RlI "id=\"kw\"" * `
From the man page for xargs:
Undefined behavior may occur if utility reads from the standard input.
That line isn't in the Linux man page but it is present on my Mac. If you want to run a program that you intend to read standard input, the usual linux version of xargs will need an argument to read its input from a file:
OPTIONS
--arg-file=file, -a file
Read items from file instead of standard input.
If you use this option, stdin remains unchanged
when commands are run. Otherwise, stdin is
redirected from /dev/null.
Vim is intended to run with both standard input and standard output connected to real (a very rare case these days) or pseudo tty devices. Wierd things will happen if you upset this arrangement.
The fundamental problem with your command was that, with standard input redirected to the pipe, xargs had no way to run a vim with a "normal" standard input. So the vim mode changes and command input were not what you expected.
You can probably fix this by typing a return, a tilde, and a period. This will force your ssh session closed from your end, you can then ssh in again, and run "ps" to check for anything left hung in the background that you should kill(1).
You can use :next or :n to get to the next file to edit. You can also use vim -o to open up all the matching files in different windows in Vim.
Not sure why your console is messed up though. I tried using your command and my console was fine.
Console options are set by stty, so you may want to save its options to a bash variable and restore them after vim exits, like this:
function vim()
{
STTYOPTS="$(stty --save)"
vim "$#"
stty "${STTYOPTS}"
}
But it is probably the better way to use zsh for this task: if you put the only line ttyctl -f into your ~/.zshrc, then zsh will automatically restore terminal options after program exits. ttyctl is a zsh builtin, so you cannot use it from bash.
Other folks covered what happened and what to do about it. As to why, the answer to that probably lies in what input Vim received from the xargs command and tried to execute as if that input came from a terminal. I don't know how to talk terminal, but you can imagine that Vim got some strange commands that crashed it or told it to quit. Similarly unpredictable things happen when you cat a binary file.
Anway, I have another idea. Have you tried using vimgrep to browse a list of files matching a pattern?
:vimgrep /id="kw"/ *
:copen
This greps for id="kw" in all files in the current directory. :copen opens up a window with a list of matches. You can browse that list, clicking enter to jump to a file position.
For more information, see
:help grep
:help :vimgrep
:help :copen
:help quickfix
If you really need that -I option, see
:help :grep
:help 'grepprg'
See also: Vim: Warning: Input is not from a terminal
Try to use ... | xargs sh -c '...' and then read from the controlling terminal device /dev/tty.
echo ~/.profile ~/.bashrc | xargs sh -c 'vim "$#" </dev/tty' dummy_script_name
# based on a tip by Laszlo Ersek on http://unix.derkeiler.com/Newsgroups/comp.unix.programmer/2010-03/msg00051.html
#find . -maxdepth 1 -type f | xargs sh -c 'rm -i "$#" </dev/tty' dummy_script_name

Resources