My workflow always consists of opening a new terminal window, typing ssh user#domain.com (or scp) followed by cd remote/directory/of/project
The domain is long and hard to type, as well as it being a big file path so this takes me ~20 seconds every time. What's the canonical, efficient way to do this that you would see a senior dev doing?
For not retyping ssh user#domain.com that often, you can put it in you .ssh/config:
Host my_alias
HostName domain.com
User user
Afterwards, you can just type ssh my_alias.
For not retyping the path, you can
put the path in an alias in your .bashrc (alias cd_my_proj='cd remote/directory/of/project')
look it up in your bash history (usually with Ctrl+R)
use a soft link (ln -s remote/directory/of/project ~)
keep the path open in a tmux (or screen) session
You may also google these pointers for more details (like how to save tmux session and further details in your .ssh/config)
You can create a script file with the commands you want to execute so you can just execute it instead of manually typing your ssh/scp/cd commands every time you have to do so.
Related
The scrolling is soo slow in TMUX 2.7+. I have a TMUX session with a window that has 5,000 lines of code and I'd like to access a command that I sent around line 2,000. It would take forever to load it up.
I've tried going into command mode and putting in the number.
How do I access a specific line in a tmux session?
The goto-line command lets you jump directly to given line. If you use vi mode, it's :2000. If you use emacs mode, it's g2000.
I run SAS batch jobs on a UNIX server and usually encounter the problem that I cannot overwrite sas datasets in batch that have been created by my user locally without changing the authorization level of each file in Windows. Is it possible to signon using my user id and password when initializing the batch job to enable me to get full authorization (to my own files) in batch?
Another issue is that I don't have authorization to run UNIX commands using PIPE on a local remote session on the server and can hence not terminate my own sessions. It is on the other hand possible to run PIPE in batch, but this only allows me to terminate batch jobs so I also wonder if it is possible to run a pipe command in batch using my id and password as the batch user does not have authorizatio to cancel "local remote sessions" on my user?
Example code for terminating process:
%let processid = 6938710;
%let unixcmd = "kill &processid";
%PUT executing &unixcmd;
filename unixcmd pipe &unixcmd.;
there's a good and complete answer to your first point in the following SAS support page.
You can use the umask Unix command to specify the default file permission policy used for the permanent datasets created during a SAS session (be it batch or not).
If you are lauching a Unix script which invokes a SAS batch session you can put a umask command just before the sas execution.
Otherwise you can adopt a more permanent solution including the umask command in one of the places specified in the above SAS support article.
You are probably interested in something like:
umask 002
This will assign a rw-rw-r-- file permission to all new datasets.
I am trying to make a folder to go on a server, that people can add photos to and then the script sends them to the correct place, however I'm having trouble with the search part.
As you can see below in my code, the part where it finds where to send the folder to is commented out, because I have no idea what the syntax is for it.
Any help would be greatly appreciated.
global theWatchedFolder
set theWatchedFolder to choose folder
on idle
tell application "Finder"
set theDetectedItems to every item of theWatchedFolder
repeat with aDetectedItem in theDetectedItems
set jobNumber to display dialog "Please enter the job number for this photo." buttons {"Submit", "Cancel"}
display dialog "File detected: " & jobNumber
--tell finder
-- search for jobNumber in (path to desktop)
--set jobFolder to top search result
--end tell
--set colourFolder to jobfolder & /colour
move aDetectedItem to the desktop --move to colourFolder
end repeat
end tell
if theDetectedItems is not {} then
activate
display dialog "test move complete"
end if
return 1
end idle
Also, I am concerned that if this script is on the server, watching a folder on the server, then it won't create a pop-up for anyone who adds a file to the folder on the server. Hopefully I am wrong but if someone could confirm this one way or the other then that would be awesome. Thanks :)
I can confirm your biggest fear. The display dialog is shown in the Finder who is targeted. You'll always address the Finder on the same machine that is running your script, unless your using remote events. If the script is running on the server, the dialog will appear in the Finder running on the server.
I have also a side note that you continuously keep running AppleScript using an idle handler to check for any updates in a particular folder. Did you know that AppleScript has memory leaks as an stay open application? It's software you don't want to run constantly on a server. It's better to start a new AppleScirpt in a new process once in a while (I prefer something like every hour) and quit the current running one. You can still use the idle handler but if the idle handler runs every 10 seconds I would quit this script and start a new one after 600 loops.
Then back to your search. Finder doesn't have a search command. Since Mac OS X Tiger Apple introduced spotlight, a meta database for finding different kind of data (files, bundles, mails, etc). However spotlight has never been scriptable but for AppleScript only accessible on the command line using mdls, mdfind and mdutil. To execute commands on the command line we use the do shell script command in AppleScript or do script command for scripting the Terminal.app. Here an example of how to use with a do shell script command
set theFolder to choose folder
set searchKey to "the*" --use * as wild card
findMetaDataInFolderByName(theFolder, searchKey)
on findMetaDataInFolderByName(HFSPath, searchKey)
set options to " -onlyin " & quoted form of POSIX path of HFSPath
set options to options & " \"kMDItemFSName == " & quoted form of searchKey & "\""
return paragraphs of (do shell script "mdfind " & options)
end findMetaDataInFolderByName
note: because we're working in the shell the paths returned are posix path which can be used anywhere by prefixing the path with posix file
But, you have mentioned that the search has to be invoked on a server. Normally when your have a server properly installed the shares are outside the application and user home folder. These folders are by default only indexed by spotlight so spotlight needs to index on the fly. In other words it's very slow compared to normal spotlight searches with are done in less than a second. So I would suggest another version of the same script as above but using find. Find will simply walk recursively to the given directory and print every match.
set theFolder to choose folder
set searchKey to "the*" --use * as wild card
findFilesInFolderByName(theFolder, searchKey)
on findFilesInFolderByName(HFSPath, searchKey)
--the HFSPath can't have a trailing "/"
set UFSPath to POSIX path of HFSPath
if UFSPath ends with "/" and UFSPath is not "/" then set UFSPath to text 1 thru -2 of UFSPath
set options to space & quoted form of UFSPath
set options to options & " -iname " & quoted form of (searchKey) --iname is case insensitive file name match
paragraphs of (do shell script "find " & options & " -print 2>/dev/null ; exit 0") --pipe error to /dev/null to exclude permission denied messages
end findFilesInFolderByName
note: A side effect is because find will try every file while meta data search works different you'll probably find more files now because folders are included in the search as well. Just like findMetaDataInFolderByName(), findFilesInFolderByName() will return posix paths.
I created a client-server application and now I would like to deploy it.
While development process I started the server on a terminal and when I wanted to stop it I just had to type "Ctrl-C".
Now want to be able to start it in background and stop it when I want by just typing:
/etc/init.d/my_service {stop|stop}
I know how to do an initscript, but the problem is how to actually stop the process ?
I first thought to retrieve the PID with something like:
ps aux | grep "my_service"
Then I found a better idea, still with the PID: Storing it on a file in order to retrieve it when trying to stop the service.
Definitely too dirty and unsafe, I eventually thought about using sockets to enable the "stop" process to tell the actual process to shut down.
I would like to know how this is usually done ? Or rather what is the best way to do it ?
I checked some of the files in the init.d and some of them use PID files but with a particular command "start-stop-daemon". I am a bit suspicious about this method which seems unsafe to me.
If you have a utility like start-stop-daemon available, use it.
start-stop-daemon is flexible and can use 4 different methods to find the process ID of the running service. It uses this information (1) to avoid starting a second copy of the same service when starting, and (2) to determine which process ID to kill when stopping the service.
--pidfile: Check whether a process has created the file pid-file.
--exec: Check for processes that are instances of this executable
--name: Check for processes with the name process-name
--user: Check for processes owned by the user specified by username or uid.
The best one to use in general is probably --pidfile. The others are mainly intended to be used in case the service does not create a PID file. --exec has the disadvantage that you cannot distinguish between two different services implemented by the same program (i.e. two copies of the same service). This disadvantage would typically apply to --name also, and, additionally, --name has a chance of matching an unrelated process that happens to share the same name. --user might be useful if your service runs under a dedicated user ID which is used by nothing else. So use --pidfile if you can.
For extra safety, the options can be combined. For example, you can use --pidfile and --exec together. This way, you can identify the process using the PID file, but don't trust it if the PID found in the PID file belongs to a process that is using the wrong executable (it's a stale/invalid PID file).
I have used the option names provided by start-stop-daemon to discuss the different possibilities, but you need not use start-stop-daemon: the discussion applies just as well if you use another utility or do the matching manually.
I have a bit of a problem with Xen. Each time I try to run xm create I get the following error:
dom0:~# xm create -c staros.xm
Using config file "./staros.xm". Started domain StarOS-3 xenconsole: Could not read tty from store: No such file or directory
Is this familiar to anyone?
I believe my config is in order. At first I suspected the path to qemu-dm wasn't set correctly.
The error you are describing could mean two things:
It is documenting a well known race in xenstore
The psuedo TTY needed to attach to a domain's console is stored in xenstore in several places. The Xen console client establishes an inotify style watch on that value, so that it can reconnect to the console if the backing file descriptor happens to change. However, takes a few seconds for that information to be populated in xenstore from the time that the domain is initially created.
If you post the output of xm info, it would be easy to see if you are dealing with a well known race.
The backing psuedo terminal can't be created
Common reasons for this would be /dev/pts not being mounted. If you run xenstore-ls /local/domain/{domain_id} after starting the domain without the -c option, you will see the contents of the store for that domain. Look for the line (near the bottom) that says
tty="/dev/pts/{pty}"
Verify that the pty does, in fact, exist.
The xen console daemon uses two actual file descriptors to make it happen. The first is a psuedo file descriptor (obtained via xs_fileno()) on that specific piece of information in the node, so it can poll() to see if that information changes. The second is a real FD returned from open() (yes, O_NONBLOCK is passed) which actually reads/writes to the psuedo tty.
It looks like it's not even finding the psuedo FD from xenstore, which means the backing pty is likely existentially challenged.