I'm running my teamcity agent in linux. The first step of the build will get the version of a package using a command line script, which contains the following:
$versionNumber = grep "<Version>" %env.RelativeProjectPath% | sed -e "s/<[^>]*>//g"
The problem is that I receive this error:
/BuildAgent/temp/agentTmp/custom_script5887915083946808286: line 1: versionNumber =: command not found
Any ideas why this happens or how to fix it?
Problem solved using this:
versionNumber=$(grep '<Version>' %env.RelativeProjectPath% | sed -e 's/<[^>]*>//g')
Related
My working directory is as follows:
MyWorkDirectory
└── test
The file "test" contains a line of information：
1:2:3:4:5
When I use the following command:
cat test foo
the output is as follows:
1:2:3:4:5
cat: foo: No such file or directory
I want to ignore STDOUT and only deal with STDERR, and I want to use the cut command to get the third STDERR segment separated by the ":"，So I tried the following command：
cat test foo 2>&1 1>/dev/null | cut -d ':' -f 3
I think the output here should be as follows:
No such file or directory
However, there are many different outputs here：
1、
1
No such file or directory
2、
No such file or directory
3
3、
2
4、
...
Why are these outputs generated? What commands should I use if I want to achieve my goal?
The issue here is "multiple redirect".
The reason this can not be reproduced on Ubuntu, is because Ubuntu (like many Debian based Linux distros) uses Ash or Bash shell by default, while recent MacOS version switched to using ZSH.
ZSH on Ubuntu will give similar result to what you are getting.
Apparently, using both redirect > and pipe | causes ZSH to split you stderr similar to tee command.
This post shows a solution to the problem:
https://unix.stackexchange.com/questions/265061/how-can-i-pipe-only-stderr-in-zsh
Specifically, you need to close stdout before redirecting it to /dev/null to prevent the split:
cat test foo 2>&1 >&- > /dev/null | cut -d ':' -f 3
This works with ZSH on Ubuntu, and should work on Mac OS.
If it does not, check the linked post for enabling mult_ios option in your shell.
I am running some code which necessitates the usage of the following line exactly:
cat data/train.txt | cut -d$'\t' -f 2 | grep -v "^$"| sort | uniq > data/labels.txt
Does Anyone know how this line of command can be translated to a Windows command - or what it means?
P.S. I have been trying to run the code through WSL on my Windows, and the line does execute correctly, however the package I'm trying to use necessitates use of Pytorch with GPU access, which WSL does not facilitate, thus the need to use it on the Windows command line
The Answer was provided by #a_horse_with_no_name, as downloading the utix utilities for windows from: unxutils.sourceforge.net
I am using the windows rewrite of SED from http://sed.sourceforge.net/grabbag/ssed/ to try and remove all script tags from a file. I am using this command
sed "/<script/,/<\/script>/d" "C:/myfolder/test.html"
But this is not working for me and is just returning the word 'test'
I know this might be an issue with the windows version of sed but in terms of the command, does it look correct?
You can test such utilities online for example on rextester.
The following:
echo 'abc
<script>
def
</script>
xyz' | sed "/<script/,/<\/script>/d"
outputs:
abc
xyz
so it looks ok.
Maybe you are using a wrong file?
You can also install cygwin on windows and install a good sed with cygwin.
On Linux I'm using "tee" to capture the output of "source" command and print it to output log file, but failed. The command I'm using is like this:
source ./my_run.sh 2>&1 | tee -i my_run_log
The intention of my_run.sh is to "make" some compile job, as well as some routine jobs like cd, rm and svn update. The content of my_run.sh is like follows:
make clean
cd ..
rm ./xxx
svn up -r 166
cd ./aaa/
sed -i -e ......
make compile
make run
However, when I run it the "tee" just does NOT work, and do NOT give me the log file at all. In order to verify that the entire environment is good, I did a simpler test with:
ll 2>&1 | tee -i log
and in this simpler scenario the "tee" works perfectly fine and prints out "log" as I expected.
Can anyone help me find out where my problem is?
btw,
I'm working on Red Hat Linux (Release 5.9), using bash shell.
Thanks in advance!
SOME MORE COMMENTS:
I did some more tests and found that as long as the my_run.sh script has got "make xxx" stuffs in it, then "tee" will fail. Seems like tee does NOT like make. Any solutions?
Problem solved; many thanks goes to #thatotherguy in leading me to the solution. The log output was actually deleted by the make clean process. After fixing the clean stuff in the makefile, everything is good.
I've created a npm module that I intend to publish, but not without testing that it works first. So I install the module I'm working with, npm install -g . and it works well on my Windows computer, but it won't run on my Linux (Debian) computer. Instead I get the following error:
15:52 $ transval
: No such file or directory
The only thing I've found so far when I compare the generated cmd and bash file on my windows computer is that whilest (when comparing to, say, 'gulp') the cmd-files are identical in structre the bash files are not. The second line, where the basedir is set differs. This the full output of the published bash file for my module:
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
"$basedir/node" "$basedir/node_modules/transval/bin/transval.bin.js" "$#"
ret=$?
else
node "$basedir/node_modules/transval/bin/transval.bin.js" "$#"
ret=$?
fi
exit $ret
But if I compare the top two lines with any other file there is a significant difference! This is the top two lines from any other module, such as gulp:
#!/bin/sh
basedir=`dirname "$0"`
All other bash files get that dirname. If I change my bash file to that basedir it all of a sudden works. It is driving me mad!
EDIT:
These two files are created when I run the command npm install -g . (thus installing my package globally for testing) or when I have published (i.e. npm publish), so I'm not generating these files my self.
My package.json has a bin entry which points at a file that looks like this:
#!/usr/bin/env node
var app = require('../bundle.js');
app.init(process.argv);
Anyone have any idea why it would work on Windows and not in Linux?
Ok, found the problem. It seems to have been a problem with publishing from Windows. Once I had published from Linux (Ubuntu in this case) I could install it on both Linux and Windows computers.
I'm not sure what the reason for this is, be it some npm bug or an issue with doze line breaks, but now it's working :)
I did try to publish previously from Linux, and failed, but with an old version of Node (4.something) and that didn't work but now I've upgraded to the latest version and it works well, so that might've had something to do with it.
Edit:
I can now verify that publishing on a Debian machine running node 6.2.2 creates an unusable published version whereas publishing on a Ubuntu machine running node 7.4.0 works well and can be installed and run anywhere. Both machines are running npm version 4.0.5.
Edit Per additional information in the OP's answer, it is indeed a line-ending problem. The problem actually is not related to $() vs. ``.
When generating on Windows, the lines end with a carriage return and a linefeed, \r\n. However, when running the generated script on Debian, only the \n is taken as the end of line. As a result, the assignment to basedir is effectively:
basedir=$(dirname "...")$'\r'
# ^^^^^ Carriage return! Oops!
I think that is why the error message was ': No such file or directory': before the :, the contents of $basedir were actually printed, ending with the \r. The \r moved the cursor back to the beginning of the line, then the rest of the error message, beginning with :, overprinted the path. (That's a guess, though — I can't reproduce the exact error message on my system.)
A workaround is to put a # (space-hash) after the basedir assignment:
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')") #
# add these ^^
That way the \r will be part of a comment and not part of basedir.
Note: see this question and its answers for other ways of getting $basedir.
Per chat, the OP is going to add the $basedir values for both options tomorrow.
For reference, here's where we are at present:
Per this answer, npm generates the wrapper scripts based on bin entries in the package.json.
npm uses the cmd-shim module to make the scripts.
cmd-shim was updated 2013/10/28 to use the dirname ... echo ... sed sequence so that it would work on msysgit.
gulp and other scripts using dirname "$0" were presumably generated with a cmd-shim predating that update.
The OP's Debian /bin/sh is apparently dash (currently 0.5.7-4 in debian stable).
for the OP, on Debian, bash is version: 4.3.46(1)-release and sed is version 4.2.2
I tried both basedir types on my Cygwin dash 0.5.8-3 and they both worked.
On Ubuntu, the OP has a different problem: /usr/bin/env: 'node\r': No such file or directory. That looks like a line-ending issue to me, probably different from the Debian issue.