I'm having a rather strange problem with zsh. When I start up my shell, everything - functions, environment vars, aliases, etc. - all work fine. I've created the following function and sourced it in zsh:
clean()
{
path=/tmp
for i in ${path}/*; do
echo $i
done
}
Running clean in the terminal works as expected, in that it prints out all the files in /tmp/. Afterward, however, trying any command - for example, ls - produces this:
zsh: command not found: ls
I have several other functions that work just fine, which leads me to believe that somehow, that loop is causing the problem. At any rate, this is very frustrating and I would sincerely appreciate the community's eyes. Thanks!
The problem is assigning the path variable - since zsh has that variable reserved (in addition to PATH), overwriting it removes the ability for the shell to find any command.
The correct answer, of course, is to use a variable other than $path:
local_path=/tmp
for i in ${local_path}/*; do
echo $i
done
I guess it overwrites the variable path, which is the one used to find commands. That's why it doesn't find commands anymore.
I dugg for hours to find this again. Zsh offer a nice trick to remove duplicates from PATH-type variables, a bit out of topic, but may be useful :
typeset -T PYTHONPATH pythonpath
typeset -U pythonpath
the first line bind PYTHONPATH colon separated string to zsh array
the second remove duplicates
Related
Within tclsh I can run the following and get the expected output:
% exec bash -c "ulimit -v"
50331648
However within a Tcl script nothing is returned. No error, no output, nothing. There's clearly some gotcha with exec'ing 'bash -c' that I can't work out.
Alternatively, is there a native way in Tcl that I can get the system's memory limit to avoid having to do it this way in the first place?
In an interactive tclsh session, the REPL helpfully prints the output of commands/expressions. That's not the case in a non-interactive program.
exec returns the output of the command: you just need to capture it with the usual command substitution:
set output [exec bash -c "ulimit -v"]
puts $output
The code that you wrote should work; I can't identify why bash would silently fail to run ulimit -v. Even if the script was running in an environment where that was privileged information (why!?) one would still expect to get an error message of some form. That's a very weird problem!
Tcl's base command set doesn't expose any access to memory limits, whether for reading or writing. The simplest workaround that doesn't call an external program is the tclbsd package (apparently it mostly works on most other Unixes as well), which exposes a command that should help:
package require BSD
set limit [bsd::rlimit get soft virtual]
I am trying to generate html reports through the jmeter non gui commands.
HTML reports are not getting generate and also seeing the below error with regards to the same.
COMMAND USED TO RUN:
jmeter -Jjmeter.save.saveservice.output_format=csv -Jjmeter.reportgenerator.apdex_statisfied_threshold=1500 -n -t D:\jmeter\v1_images_scenario.jmx -l D:\jmeter\images.jtl -e -o D:\jmeter\Reports\
ERROR MESSAGE:
Error generating the report:
org.apache.jmeter.report.dashboard.GenerationException: Cannot assign
"${jmeter.reportgenerator.apdex_satisfied_threshold}" to property
"set_satisfied_threshold" (mapped as "setSatisfiedThreshold"), skip it
Facing same error after setting the threshold as well .
Tried searching more on this , but couldn't be able to resolve the issue. Would be great if some once could help me on this.Thanks In Advance
Although the accepted answer resolved the OP's issue, I thought I would add an additional answer here as I ran in to this same behaviour and was unable to find a quick answer, thus wasting a lot of time searching, digging and the like.
In my scenario I had, mistakenly, changed from using -q <properties file> to -p <properties file>. What I didn't realize (at the time) is -q defines an additional properties file to be read, whereas -p overrides the jmeter.properties file. Thus when using -p I was missing properties that were required to correctly generate the dashboard. Incidentally, the "Summariser" (logger that periodically writes statistics to stdout) also stopped working, so that was an additional side effect. Interestingly my tests weren't failing, just the dashboard creation error and the missing Summariser.
Looking at the official documentation: https://jmeter.apache.org/usermanual/get-started.html#options this distinction is made, but other sites out there aren't so clear on that matter. So there you go...
You have a typo in your command, change it to look like:
jmeter -Jjmeter.save.saveservice.output_format=csv -Jjmeter.reportgenerator.apdex_satisfied_threshold=1500 -n -t D:\jmeter\v1_images_scenario.jmx -l D:\jmeter\images.jtl -e -o D:\jmeter\Reports\
i.e. change statisfied to satisfied
Going forward check the following files:
reportgenerator.properties
user.properties
jmeter.properties
For the following line:
jmeter.reportgenerator.apdex_satisfied_threshold=${jmeter.reportgenerator.apdex_satisfied_threshold}
and once found - delete or remove it, this way you will be able to generate the dashboard using default threshold of 500 if you don't override the property.
More information:
JMeter Properties Reference
Apache JMeter Properties Customization Guide
Sound as lazy as it is I was wondering if it's possible to open a file with sublime using (command line) and in the same command define the expected syntax.
Lets say on a mac we have the subl command installed, so running $ subl .bash_something will open the .bash_something then we have to chose the "shel script(bash)" syntax from the list. what would be really nice (for laze me) is to include the syntax to the command as an argument. i.e.
$ subl -x bash .bash_something
or something like that. this obviously doesn't work but I was wondering if there is similar solution or if its possible to include one
Unfortunately, there is no way that I can find to dynamically set the syntax from the command line. subl has the --command option, which allows you to run a Sublime command while loading the file, directory, or project indicated. However, the command to change the syntax of a view - set_file_type - takes an argument of the form ("syntax": "Packages/PackageName/SyntaxName.sublime-syntax") (or SyntaxName.tmLanguage). As far as I've been able to tell, you simply can't pass arguments to commands run via the command line. I've opened an issue to request an enhancement.
Now, this doesn't mean that all is lost. If you have just a few filetypes that are unknown to Sublime, open them, then select View -> Syntax -> Open all with current extension as... and select the syntax you want. If for some reason this isn't sufficient, or would like finer-grained control over exactly which filenames (not just which extensions) get opened as what, check out the ApplySyntax plugin. It allows you to use regexes to open exactly which file patterns you define as what syntax.
Commands can take arguments in Sublime 3 now. I was able to achieve this functionality with a bash function.
You can pass arguments to the --command option with inline JSON and escaped quotes. This command will change the syntax to Bash for the current active file in Sublime:
subl --command "set_setting {\"setting\": \"syntax\", \"value\": \"Packages/ShellScript/Shell-Unix-Generic.sublime-syntax\"}"
I created a simple bash function and sourced it in my .bash_profile to wrap these two commands together to activate/open a file then change the synax:
function subl_bash() {
subl "$1" && subl --command "set_setting {\"setting\": \"syntax\", \"value\": \"Packages/ShellScript/Shell-Unix-Generic.sublime-syntax\"}"
}
I have written a backup script that uses expect to automate rsync.
To make sure all files get backed up, I use rsync's --rsync-path="sudo rsync" option.
#!/bin/bash
set -e
expect <<- DONE
spawn rsync --rsync-path="sudo\\ rsync" -uav myuser#example.com:/home/myuser/ /backups/home/myuser
expect ":"
send -- "mypassword\r"
expect eof
DONE
This does not work as intended. I get the following error message:
bash: sudo rsync: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.1]
I have seen similar questions with respect to using spaces in a rsync command line, and have added single quotes, double quotes, and escape backslashes here and there, but nothing has worked yet.
How do I make "--rsync-path with spaces" work within an expect script?
The problem is that you've got this:
--rsync-path="sudo\\ rsync"
Inside Expect/Tcl, this is seen as:
--rsync-path="sudo rsync"
And, because Tcl's quoting rules are not the same as bash's, that then uses "sudo rsync" with the double quotes as the command to send to the remote side. Which confuses things terribly. The correct fix is to omit the double quotes; the (backslash-quoted) backslash will ensure that it all gets into spawn as one argument, and gets sent to the other side correctly.
I really don't like using HEREdocs with Tcl. Too many things can go weird when different sorts of quoting interact. It's much better to use a single script in the real target language, since then you can use variables to make things clearer:
#!/usr/bin/env expect
set remoteRsync "sudo rsync"
set from myuser#example.com:/home/myuser/
set to /backups/home/myuser
set pass "mypassword"
spawn rsync --rsync-path=$remoteRsync -uav $from $to
expect ":"
send -- "$pass\r"
expect eof
exit
This makes the structure of the code much simpler to see, and easier to debug. The bit with /usr/bin/env at the start is just a way to avoid having the bash wrapper.
And no, those variables won't need quoting at use. Tcl is not bash.
You can't use --rsync-path to do that, since what you want is word-splitting, i.e. something the shell does.
So how can you run a command that runs a command by specifying a single pathname?
On the remote system, write a script wrapper susync doing the sudo (don't forget to chmod 755):
#!/bin/sh
exec /path/to/sudo /path/to/rsync "$#"
and use
spawn rsync --rsync-path=/path/to/susync ...
I noticed that I can't combine --traditional options with the other one letter other options such as -i for example.
For example, when I have this as the first line in my octave .m file
#!/usr/bin/octave --traditional
Then it work. Octave starts ok and runs the script.
But when I try
#!/usr/bin/octave --traditional --silent --norc --interactive
It does not work. Error from octave. does not understand the options.
When I try
#!/usr/bin/octave --traditional -qfi
Also error. But this
#!/usr/bin/octave -qfi
works.
The problem is that --traditional does not have a one letter short cut like all the other options. This is the options I see
Options:
--debug, -d Enter parser debugging mode.
--doc-cache-file FILE Use doc cache file FILE.
--echo-commands, -x Echo commands as they are executed.
--eval CODE Evaluate CODE. Exit when done unless --persist.
--exec-path PATH Set path for executing subprograms.
--help, -h, -? Print short help message and exit.
--image-path PATH Add PATH to head of image search path.
--info-file FILE Use top-level info file FILE.
--info-program PROGRAM Use PROGRAM for reading info files.
--interactive, -i Force interactive behavior.
--line-editing Force readline use for command-line editing.
--no-history, -H Don't save commands to the history list
--no-init-file Don't read the ~/.octaverc or .octaverc files.
--no-init-path Don't initialize function search path.
--no-line-editing Don't use readline for command-line editing.
--no-site-file Don't read the site-wide octaverc file.
--no-window-system Disable window system, including graphics.
--norc, -f Don't read any initialization files.
--path PATH, -p PATH Add PATH to head of function search path.
--persist Go interactive after --eval or reading from FILE.
--silent, -q Don't print message at startup.
--traditional Set variables for closer MATLAB compatibility.
--verbose, -V Enable verbose output in some cases.
--version, -v Print version number and exit.
I am mainly interested in running octave code that is compatible with Matlab, so I'd like to use this --traditional option to make sure I keep the code compatible with Matlab in case I need to run the same code inside Matlab as well.
Or may be I can "turn on" this compatiblity mode once octave starts using a different command?
I am using GNU Octave, version 3.2.4 on Linux.
thanks
I don't think this is really an octave problem, per se. The Unix shebang notation in general is somewhat limited. I don't know the exact limits off the top of my head, but I'm pretty sure many implementations aren't happy if you add more than one option to the shebang line, which seems to be your problem.
Using a wrapper script is probably the canonical way to get around such problems.
To address your question of combining short and long options, Unix conventions don't allow for this. You could consider patching octave to add a short option for --traditional, if this is feasible for you. Alternatively, I'd imagine there's a way to specify the traditional behavior in the user or system-wide Octave configuration file, but this might not be that helpful if you need the script to work on systems you don't control.