I'm trying to use a shell variable in Tmux to configure some settings for the venerable powerline. The line of interest in my .tmux.config is:
run-shell "powerline-daemon -q"
source-file $POWERLINE_ROOT/powerline/bindings/tmux/powerline.conf
I get the following error :
/Users/myname/.tmux.conf:47: /powerline/bindings/tmux/powerline.conf: No such file or directory
It seems that the value of the environment variable $POWERLINE_ROOT is not being seen by Tmux. (I can confirm that $POWERLINE_ROOT does have a non-empty value.)
You can see my complete Tmux configuration if needed
Here's all I know:
I have the following in my .bashrc:
export __tmux_bg_inactive='234'
export __tmux_bg_active='233'
export __tmux_fg_inactive='245'
export __tmux_fg_active='248'
I have the following in my .tmux.conf:
set -g window-style "fg=colour${__tmux_fg_inactive},bg=colour${__tmux_bg_inactive}"
set -g window-active-style "fg=colour${__tmux_fg_active},bg=colour${__tmux_bg_active}"
set -g pane-active-border-style "fg=colour$__green, bg=colour$__tmux_bg_active"
set -g pane-border-style "fg=colour$__tmux_fg_inactive, bg=colour$__tmux_bg_inactive"
This works for me. Maybe the fact that I've export'd the variable is what did it, or maybe it's that it's in my .bashrc so it gets set everywhere tmux could possibly need it?
Let me know if that doesn't work.
Related
I'm following this Go + GraphQL tutorial https://www.howtographql.com/graphql-go/4-database/ and I got stuck at the point where I'm trying to install and then run migrations.
The entire command chain is
go get -u github.com/go-sql-driver/mysql
go build -tags 'mysql' -ldflags="-X main.Version=1.0.0" -o $GOPATH/bin/migrate github.com/golang-migrate/migrate/v4/cmd/migrate/
cd internal/pkg/db/migrations/
migrate create -ext sql -dir mysql -seq create_users_table
migrate create -ext sql -dir mysql -seq create_links_table
But specifically in
go build -tags 'mysql' -ldflags="-X main.Version=1.0.0" -o $GOPATH/bin/migrate github.com/golang-migrate/migrate/v4/cmd/migrate/
cd internal/pkg/db/migrations/
I will get the following error in my terminal:
go build github.com/golang-migrate/migrate/v4/cmd/migrate: copying /var/folders/f9/d6pn7fz92w53vcpywqd_08zm0000gp/T/go-build1656176552/b001/exe/a.out: open /bin/migrate: operation not permitted
How to solve this?
$GOPATH is not set (which is fine and go will fallback to default value).
That causes $GOPATH/bin/migrate evaluate to /bin/migrate instead of its expected value - something like /home/you/go/bin/migrate (where /home/you/go is default $GOPATH).
To use the default value in case $GOPATH is not set; your go build command should call $(go env GOPATH) instead of using $GOPATH directly:
go build -tags 'mysql' -ldflags="-X main.Version=1.0.0" -o $(go env GOPATH)/bin/migrate github.com/golang-migrate/migrate/v4/cmd/migrate/
That tutorial is simply making wrong assumption that $GOPATH environment variable is always set.
I have tried to implement - https://github.com/Autodesk-Forge/forge-bim360-data.connector.dashboard
I have updated this part - npm install set FORGE_CLIENT_ID=<<YOUR CLIENT ID FROM DEVELOPER PORTAL>> set FORGE_CLIENT_SECRET=<<YOUR CLIENT SECRET>> set FORGE_CALLBACK_URL=<<your callback url of Forge e.g. http://localhost:3000/oauth/callback>> set DC_CALLBACK_URL=<<"your ngrok address here: e.g. http://abcd1234.ngrok.io/job/callback">>
I am getting the error that 400-Unknown or invalid client_id
Firstly, I rarely used Windows OS now. I simply copied the guideline of setting environment variables from other samples, while most time, I tried with debug mode (setting environment variables in launch.json) .
checking the Readme again, I found the wording is:
Windows (use Node.js command line from Start menu)
i.e. it asks to input those commands to command line of Node.js, instead of terminal of VSCode! That is why it always reports the error of client id is not defined because the variables are not set to environment at all.
The correct way is to open the command line of Node.js, and run the commands. This is a screenshot.
I'm running a test with JMeter 2.1.13 on Ubuntu 14.04, getting the output as csv. I use the following command line in Ubuntu 14.04 to try to get it to read the properties file to add fields to the CSV output
./jmeter -n -p /opt/apache-jmeter-2.13/bin/jmeter.properties -l n1.csv -t Apache-DB.jmx
With the following in the properties file
jmeter.save.saveservice.output_format=csv
jmeter.save.saveservice.print_field_names=true
jmeter.save.saveservice.response_code=true
jmeter.save.saveservice.successful=true
jmeter.save.saveservice.latency=true
jmeter.save.saveservice.connect_time=true
jmeter.save.saveservice.bytes=true
jmeter.save.saveservice.default_delimiter=,
It doesn't seem to pick it up, as no field headers are printed. Here's an example from the first line of the csv file
1448233211742,313,HTTP Request,200,OK,Thread Group 1-1,text,false,209666,1,1,96
I've also tried --propfile instead of -p, which didn't work. Am I doing something wrong or does JMeter not read those configuration options like it should?
Background information / helpful information for others
I have managed to turn on a couple of extra fields using command line switches (just in case anyone finds this on Google). This at puts field labels on the JMeter CSV output.
./jmeter -n -Jjmeter.save.saveservice.print_field_names=true -Jjmeter.save.saveservice.connect_time=true -l n1.csv -t Apache-DB.jmx
For reference here are the JMeter default csv fields
timeStamp,elapsed,label,responseCode,responseMessage, threadName,dataType,success,bytes,grpThreads,allThreads,Latency
The header at the top of jmeter.properties advices:
################################################################################
#
# THIS FILE SHOULD NOT BE MODIFIED
#
# This avoids having to re-apply the modifications when upgrading JMeter
# Instead only user.properties should be modified:
# 1/ copy the property you want to modify to user.properties from jmeter.properties
# 2/ Change its value there
#
################################################################################
Your settings are likely being overridden when default saveservice properties are loaded afterjmeter.properties.
Try putting your properties in user.properties.
I am running GridEngine (GE 6.2u5) jobs from a command line. For example,
qsub echo "Hello"
But I get this error,
Unable to read script file because of error: error opening echo: No such file or directory
The workaround is easy, use the -b y flag. I'd like to create an SGE properties file in my home directory which will set '-y' to be the default. How do I do this?
If you want to add your option, you can edit the file "sge_request". It allows you to set the default options that will be added to any requests you will submit.
This file is situated in : SGE_ROOT/CELL_NAME/common/sge_request
For more information, check the documentation : http://gridscheduler.sourceforge.net/htmlman/htmlman5/sge_request.html
I am getting this error with GT.M:
%GTM-E-GDINVALID, Unrecognized Global Directory file format: /home/blah/gt.m/example/mumps.gld, expected label: GTCGBDUNX007, found: GTCGBDUNX006
Here is what I did so far:
get the version http://sourceforge.net/projects/fis-gtm/
tar -xzf gtm_V55000_linux_i686_pro.tar.gz
chmod +x semstat2 mupip mumps lke gtmsecshr gtcm_shmclean gtcm_server gtcm_play gtcm_pkdisp gtcm_gnp_server geteuid ftok dse
Now we start like this in Bash:
mkdir example; cd example
...and invoke the mumps from the parent dir:
../mumps -r GDE
The output is this:
%GDE-I-GDUSEDEFS, Using defaults for Global Directory
/home/blah/gt.m/example/mumps.gld
Now we set the working dir to create the gld file.
GDE> change -s DEFAULT -f=/home/blah/gt.m/gt.m/example/
GDE> exit
The output from the command is this :
>%GDE-I-VERIFY, Verification OK
>%GDE-I-GDCREATE, Creating Global Directory file
> /home/blah/gt.m/example/mumps.gld
Now this creates a v6 version of gld, which mupip does not like:
strings mumps.gld | head -1
Which contains this string:
GTCGBDUNX006H
But mupip expects a 7 not a 6!
../mupip create
>%GTM-E-GDINVALID, Unrecognized Global Directory file format: >/home/blah/gt.m/example/mumps.gld, expected label: GTCGBDUNX007, found: GTCGBDUNX006
If I just edit the file and replace the 6 with a 7,
../mupip create.
This works!
Now I have a dat file, and go to gtm to save something :
GTM>s ^foo("blah")=1
%GTM-E-GDINVALID, Unrecognized Global Directory file format: >/home/blah/gt.m/example/mumps.gld, expected label: GTCGBDUNX006, found: GTCGBDUNX007
Oh so that wants a v6, so good thing i backed up the old, one, i replace it .
GTM>s ^foo("blah")=1
that works
GTM>zwr ^foo(*)
>^foo("blah")=1
So the data is stored.
Can anyone please explain this? In detail? Why does mupip operate with a different version number?
Note, I did not run any other commands, I am just learning and don't want to execute any huge install routines a root that I don't understand.
In your steps you don't show whether you installed GT.M or not.
That is only the unziped version, first:
chmod 777 configure
./configure
The installation will produce new files in the gtm_dist directory.
You either have GT.M already installed (and I would guess it is an older version) on your system somewhere else and have some environment variable defined for it in your bash/tcsh/*sh environment, or you didn't provide all the step you did to get to that error.
My guess is that you already have GT.M installed somewhere and your above commands uses part of that installation. You can easily verify this using this command : env | grep gtm.
If I follow your steps mentioned above, I get this result :
laurent#laurent /tmp/test $ tar -zxf ~/Projects/gtm_V55000_linux_i686_pro.tar.gz
laurent#laurent /tmp/test $ chmod +x semstat2 mupip mumps lke gtmsecshr gtcm_shmclean gtcm_server gtcm_play gtcm_pkdisp gtcm_gnp_server geteuid ftok dse
laurent#laurent /tmp/test $ mkdir example; cd example
laurent#laurent /tmp/test/example $ ../mumps -r GDE
%GTM-E-GTMDISTUNDEF, Environment variable $gtm_dist is not defined
So, I as said, you either did something else, or have a different GT.M version already installed and this is why some commands expect different versions of GLD.
As Bhaskar has noted in your cross post on Hardhats. Make sure you follow the installation instructions for GT.M. Instructions can be found in Chapter 2 of the UNIX Administration and Operations Guide