Im my Capistrano deployment setting file I have to grab a domain in variable. Problem is that the domain contains hyphen :
set :production_domain, 'www.my-domain.com'
I was woundering if I can escape hyphen in the variable?
Thanks
This should do the trick:
set :'production-domain', 'www.my-domain.com'
Then:
fetch(:'production-domain')
Related
I'm trying to deploy a function using gcloud and powershell.
While doing that I want to set multiple environment variables.
Current script looks like this
--set-env-vars folder_id=$FOLDER_ID,SECRET_NAME=$SECRET_NAME,GCP_PROJECT=$PROJECTID
And this sets only 'folder_id' and takes all the strings after the first = including the rest of commas and equal signs as its value.
I know I can also use env-var-file but as you can see I want these values to be variables people can dynamically set.
What is the right syntax to do this?
So far I've tried,
# with quotation mark
--set-env-vars "folder_id=$FOLDER_ID,SECRET_NAME=$SECRET_NAME,GCP_PROJECT=$PROJECTID"
# with equal from the beginning
--set-env-vars=folder_id=$FOLDER_ID,SECRET_NAME=$SECRET_NAME,GCP_PROJECT=$PROJECTID
# with quotation mark AND equal from the beginning
--set-env-vars="folder_id=$FOLDER_ID,SECRET_NAME=$SECRET_NAME,GCP_PROJECT=$PROJECTID"
# with square brackets
--set-env-vars=[folder_id=$FOLDER_ID,SECRET_NAME=$SECRET_NAME,GCP_PROJECT=$PROJECTID]
# Passing an array of strings
$ENV_VARS = #("folder_id=$FOLDER_ID","SECRET_NAME=$SECRET_NAME","GCP_PROJECT=$PROJECTID")
--set-env-vars=$ENV_VARS
Before I would go on the path to parse env.yml file from .ps1 and then execute deploying code, I wanna give it one more shot by asking the question here.
Using a separate --set-env-vars for every variable like
--set-env-vars folder_id=$FOLDER_ID --set-env-vars SECRET_NAME=$SECRET_NAME
isn't an elegant solution but it works.
I've run into an issue recently where adding a new PATH variable deletes the previous one added. However, I need to add both of these variables to PATH in order to run a python wrapper I'm working on from command line. Does this mean there is a limit to the number of variables I can add to path? And can I delete some path variables I no longer use?
For reference, I'm running Windows 10 and have been adding variables to path by going through from Control Panel to Advanced System Settings and then going from there to Environment Variables. There you can add to your PATH variable by clicking new.
Thanks in advance.
Just figured out that one way to circumvent this is to add multiple directories to PATH at once, separating them with semicolons. For example,
Variable Name = PATH
Variable Value = C:\path\to\directory1;C:\path\to\directory2\;C:\path\to\directory3
Good Day
I am trying to set these paths in powershell but have not been successful in this regard. I have a DOS script that was initially written to set these paths but now I need it set in powershell.
Primarily, these paths are still used in the script to parse information, so in the same breathe, should act as a variable as well. Please help if possible. I am aware that powershell has a Set-Location function but would it serve the purpose as described above. Here are the paths scripted in DOS below:
set CLASSPATH=D:\NetExpress\Base\Bin\WIN64\mfcobol.jar;.;%CLASSPATH%
set COBIDY=D:\NetExpress\Base\SOURCE
set COBLINK64=D:\NetExpress\Base\Bin\Linker
set COBREG_64_PARSED=True
set INCLUDE=D:\NetExpress\Base\INCLUDE
set LIB=D:\NetExpress\Base\Lib\WIN64
set MFTRACE_LOGS=D:\NetExpress\Base\MFTRACE\Logs
set SCHEMA_PATH=D:\NetExpress\Base\SCHEMA
set TXBIN=D:\NetExpress\Base
set TXDIR=D:\NetExpress\Base
set PATH=D:\NetExpress\Base\Bin\Linker;D:\NetExpress\Base\Bin\WIN64;D:\NetExpress\Base\Bin;D:\NetExpress\PACKAGES\x64;C:\Windows\System32\wbem;C:\Windows\System32\
set COBPATH64=D:\NetExpress\Base\Bin\WIN64
set LD_LIBRARY_PATH=D:\NetExpress\Base\Bin\WIN64;%int%
set COBDIR=D:\NetExpress\Base\Bin\WIN64;%int%;D:\NetExpress\MFSQL\SOURCE
set COBDIR64=D:\NetExpress\Base\Bin\WIN64
set COBPATH=%exe%
set COBCPY=%int%\LIBRYATM;%int%\LIBRYBOR;%int%\LIBRYBRO;%int%\LIBRYCHG;%int%\LIBRYCTA;%int%\LIBRYDCS;%int%\LIBRYGEN;%int%\LIBRYEN;%int%\LIBRYINV;%int%\LIBRYMIS;%int%\LIBRYSPY;%int%\LIBRYSWI;%int%\LIBRYTRE;%int%\LIBRYUNX;%int%\LIBRYCNV;D:\NetExpress\Base\SOURCE
set LogFile=%CD%\logfile.log
Assist if possible please...
It's as Mathias R. Jessen has mentioned in the comments
You'll have to use the in-built powershell variable $env.
$env has all the environment variables already defined in your system and you can add to them using
$env::VariableName = Value
Example would be something like
$env:CLASSPATH = "D:\NetExpress\Base\Bin\WIN64\mfcobol.jar;.;" + $env:CLASSPATH
If setting environment variable is your only goal then this should do it, if you are planning to use these scripts later in the same script file I'd suggest you use powershell variables instead.
Also check out this Microsoft Page for more on Environment Variables and Powershell
does anybody have idea why some windows XP installation would not evaluate path with double backslash in them?
Error is found on some XP (same build, patches, unknown more details). In most everything works, on some PCs following doesn't work:
Querying path (registry or folder) with functions like RegEnumKeyEx, fopen fails if path contains two backslashes, for example C:\\test\hello.txt.
strPath = "\SOFTWARE\Microsoft\Windows\Currentversion\run" // works
strPath = "\SOFTWARE\Microsoft\Windows\Currentversion\\run" // doesn't work
Is there some policy option or setting which can affect it?
Any help welcome,
RM
Why don't you simply modify the path to only have a single \ before using it?
Possibly completely unrelated, but in C/C++ (and other languages too) -
"c:\\\\test\hello.txt" is okay, but "c:\test\hello.txt" is not (because \t is parsed as a tab character, so you get a name that doesn't really exist).
Is there a chance the failure happens when the two backslashes don't exist, and things work when they do?
Create a file called Valid[File].txt and stick some text in it. Start powershell and go to the directory.
gc Valid[File].txt
should display the value in the file. It returns blank. If you use tab auto-completion it escapes the name:
gc 'Valid[File].txt'
but still returns nothing.
How do I reference files with brackets in their names?
Turns out the key was -literalpath. For details see this technet article
You probably need to enclose it in quotation marks: gc "Valid[File].txt"