I have a core source of code that is shared in projects. I would like to have a script that, when the 'parent' has a workspace is created, that the children have their workspaces created as well.
This would help the developers not miss any references.
Thanks for the help.
EDIT: Solution:
I created a windows CL batch that
checks if the folder exists on the file system, if not
them call accurev mkws, followed by accurev pop.
It works fine
Here is an example of the solution I came up with. It is missing items like, updating a dependency WS creation if it already exits . ... .
I created a bat file in the 'parent' stream. Then commands (in a bat file), are run to get the children.
example:
IF NOT EXIST [filesystem location for stream]
(accurev mkws -w [stream name] -b [stream name] -l [location to put the stream] accurev pop -O -R -L [location to put the stream])
else #echo ~[stream name] already exists
Related
I am using Ubuntu via WSL 2.0 on Windows 10 and would like to run Texlive from the Windows command line. To do so I prepended the Texlive folder to the path in /etc/environment (I also tried a number of other locations eg. $HOME/.bashrc):
C:\Users\scott\Documents>wsl echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/system32:...
C:\Users\scott\Documents>wsl
scott#SCOTT-PC:/mnt/c/Users/scott/Documents$ echo $PATH
/usr/local/texlive/2020/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/system32:...
Why is there a difference between these two paths? Is it possible to change the first PATH variable?
To be honest, when I first looked at this question, I thought it would be an easy answer. Oh how wrong I was. There are a lot of nuances to how this works.
Let's start with the fairly "easy" part, though. The main difference between the first method and the second:
wsl by itself launches into a login (and interactive) shell
the shell launched with wsl echo $PATH is neither a login shell nor an interactive shell
So the first will source both login scripts (e.g. ~/.profile) and interactive startup scripts (e.g. ~/.bashrc). The second form does not get to source either of these.
You can see this a different way (and get to the solution) with the following commands:
wsl -e bash -c 'echo $PATH'
wsl -e bash -li -c 'echo $PATH'
The -li forces bash to run as a login and interactive shell, thus sourcing all of the applicable startup scripts. And, as #bovquier points out in the comments, a single quote is needed here to prevent PowerShell from interpolating the $ before it gets to Bash. That, or escape it.
You should be able to run TeX Live the same way, just replacing the "echo $PATH" with the startup command you need for TeX Live.
A second option would be to create a script that both adds the path and runs the command, and just launch that script through wsl /path/to/script.sh
That said, I honestly don't think that your current login/interactive PATH is coming from /etc/environment. In my testing, at least, /etc/environment has no use in WSL, and that's to be expected. /etc/environment is only sourced by PAM modules, and with no login check performed by WSL, there's no reason to invoke PAM in either the wsl nor the wsl echo $PATH commands.
I'd expect that you still have the PATH setting in ~/.bashrc or somewhere similar), and that's where the shell is picking it up from at the moment.
While this isn't necessarily critical to understanding the answer, you might also wonder, if /etc/environment isn't used for setting the default (non-login, non-interactive) path in WSL, what is? The answer seems to be that it is hard-coded into the init that starts up WSL. That init is also what appends the Windows path (assuming you don't have that feature disabled in /etc/wsl.conf).
I'm using WSL and ConEmu build 180506. I'm trying to setup a task in ConEmu to use the current directory of the active tab when opening a new console but I cannot get it to work.
What I did is to setup the task {Bash: bash} using the instructions on this page
setting the task command as :
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -C~ -cur_console:pm:/mnt
Then following the instruction on this page, I added to my .bashrc
if [[ -n "${ConEmuPID}" ]]; then
PS1="$PS1\[\e]9;9;\"\w\"\007\e]9;12\007\]"
fi
and finally setup a shortcut using the macro :
Shell("new_console", "{bash}", "", "%CD%")
But it always open the new console in the default directory ('/home/[username]').
I don't understand what I'm not doing right.
I also noticed that a lot of environment variables listed here are not set. Basically, only $ConEmuPID and $ConEmuBuild seem to be set.
Any help would be appreciated.
GuiMacro Shell was intended to run certain commands, not tasks.
You think you may try to run macro Task("{bash}","%CD%")
Or set your {bash} task parameters to -dir %CD% and just set hotkey for your task.
Of course both methods require working CD acquisition from shell. Seems like it's OK in your case - %d shows proper folder.
I found the answer:
Shell("new_console:I", "bash.exe", "", "%CD%")
The readme is actually pretty good: https://github.com/cmderdev/cmder/blob/master/README.md
this might be a dumb question, but I checked everywhere and there's no direct answer to it.
I set up both SSH keys successfully and I can connect to my instance via terminal, but when I do "ls", it doesn't show me any output. I am using iTerm2 with zsh on my Mac but I don't think this is an issue.
Can anybody give me a hint? Thanks!
When you access a VM through SSH, your working directory is the home directory of the user specified with the SSH command, i.e. /home/username. In case you access as root, the working directory will be /root.
You can check it through the command pwd
If it is a brand new machine, it is normal that the output of 'ls' is empty since in your home directory no file matches the filters of 'ls' with no parameters. The reason is that 'ls' doesn't show filenames starting with a dot ('.') because in the Linux convention they are hidden unless you run ls -al.
You can try again with $ ls -al and you will be able to see hidden files and directories as well.
On the other hand you can create as well first an empty file and then running again 'ls':
$ touch file
$ ls
At the office, we have a shared user we use half the time. I'm trying to get screen to automatically load a custom bashrc file that I created for myself when using the shared user. So far I have this which works well:
alias screen='screen -d -R -S redhar -c /home/redhar/.screenrc bash -rcfile '\''/home/goldenuser/.bashrc_redhar'\'''
This works well for the very first window it creates. The problem comes when I create a new window. Is there anyway to get a newly created window to automatically use the same rcfile?
So far I have considered the following option, but I'm looking for a more streamlined solution along the lines of a missing GNU screen config option I overlooked or something. My proposed solution:
In regular .bashrc which gets loaded automatically:
if [[ $SCREENFLAG == "REDHAR" ]]
then
. /home/goldenuser/.bashrc_redhar
exit
fi
Set alias to:
alias screen='SCREENFLAG=REDHAR screen -d -R -S redhar -c /home/redhar/.screenrc bash -rcfile '\''/home/goldenuser/.bashrc_redhar'\'''
Discovered the solution is to create a file with
bash -rcfile /home/goldenuser/.bashrc_redhar
then set your shell command in .screenrc to it
shell='<path to file created above>'
I've been advised to remove the return command from my bashrc file in order to allow Ruby Version Manager to function properly. Do I simply delete the return command, or do I replace it with some other command? I am hesitant to mess with my System-wide shell without some proper direction. But I would really like to get RVM working as it is a time saver.
My bashrc is located in the etc directory and looks like this:
# System-wide .bashrc file for interactive bash(1) shells.
if [ -z "$PS1" ]; then
return
fi
PS1='\h:\W \u\$ '
# Make bash check its window size after a process completes
shopt -s checkwinsize
if [[ -s /Users/justinz/.rvm/scripts/rvm ]] ; then source /Users/justinz/.rvm/scripts/rvm ; fi
The last line, is an insert, described in the RVM installation.
I wouldn't. That return is probably there for a good reason. It obviously doesn't want to execute anything after that if the PS1 variable is empty.
I would just move the inserted line up above the if statement.
In addition, if that's actually in the system-wide bashrc file, you should be using something like:
${HOME}/.rvm/scripts/rvm
rather than:
/Users/justinz/.rvm/scripts/rvm
I'm sure Bob and Alice don't want to run your startup script.
If it's actually your bashrc file (in /Users/justinz), you can ignore that last snippet above.
The last line uses a file in a specific user's home directory, and as such should not be in the system-wide bashrc, since only root and that user will have access to that file. Best to place it in that user's ~/.bashrc instead.