Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
I have written a program in ruby. The output correspondng to which is really long, a couple of thousand lines.
Is there a way I can write this output to a file and not in the shell, because the shell allows you to scroll up only till a certain point? I know that I can use file.puts in place of puts. But, I want to know if there is a command using which I can achieve this without making changes in the program? For shell scripts we can do script.sh > output.txt. Similarly for a shell command as well. But what about a ruby program? It doesn't seem to be working.
The problem is that ./program.rb > output.txt redirects the output as well as the prompts for input into the text file, so you can't see what you're doing. You have several options:
Use STDERR.puts to prompt for input, so it doesn't get caught by the redirection. This is my preferred method.
Use ARGV to pass input to your program. This is a good option if you think the program isn't too hard to use without prompts.
Use File.open to create an output file and write to it directly. Sometimes this is the most sensible option, but usually you want to do one of the first two.
If the program is asking for input, maybe you can change your program to accept input from the command line (ARGV[0] etc), then redirect the output to a file :
ruby myprogram > out.txt
This worked for a simple puts output:
foo.rb:
foo = gets.chomp
puts "Input was: " + foo
Terminal:
ruby foo.rb > test.txt
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I am new to scripting. While looking at an ex-employee's R code there's a line where they call to the command line. The line/purpose is not something I know how to search for online. Any help is appreciated.
The line of code in question:
/folder1/folder2/folder3 -s file_1_name -n file_1_name -e file_2_name > file_1_name.log 2>&1
Things to note:
The syntax is bash (or derived from bash, 2>&1), though when I use the command line to check what shell is used it says tcsh (example redirect >&, no numbers).\
File names (above) are just the name, not the extension. Example: a file named "ex.sch" then file_1_name would be "ex". The only extension in the line of code is for the log file that is made.
The files are .sch files. According to this site these are for schematics, though I highly doubt that that's what they are.
The line/purpose is not something I know how to search for online. [...]
The line of code in question:
/folder1/folder2/folder3 -s file_1_name -n file_1_name -e file_2_name > file_1_name.log 2>&1
Interpreted as a Bash command line, that is executing the program or script /folder1/folder2/folder3, passing it the six command-line arguments -s file_1_name -n file_1_name -e file_2_name. It is furthermore directing the program's standard output and standard error to a file named file_1_name.log in the working directory, creating that file if it does not already exist and replacing its contents if it does. If the command works then folder3 must in fact be a regular file or a symbolic link to one, not a directory / folder.
We cannot tell you more. The significance of the command-line arguments and the behavior of the program in general are not conveyed by the name you provided. In particular, the fact that some of the arguments correspond to file names you recognize with their suffixes removed is probably meaningful, but we cannot tell you the meaning.
Additionally, you observe that
when I use the command line to check what shell is used it says tcsh
Undoubtedly you have checked what your own default shell is. That is not indicative of what shell R will use to run the command.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have an input file and a script running in unix bash.
the problem is every time i edit the input file in vi , the script takes the input file as it was inputed the first time.
How can i fix this ?
run
cat inputFile
to make sure it looks correct before passing it to your script. Try doing :wq! To make sure it will save the file even if the read only perms are set on the file. The "!" after wq will force a write despite permissions on the file.
Try typing ls -ltr inputFile and check the perms. If they look like below this then run chmod a+w inputFile
-r-r-r--
Use :w in vi to save your input file before executing the script.
Pure speculation, since many details are missing, but if your script opens the file and keeps it open, it will not see updates. If there is only one (hard) link to the file, then vi (assuming vi is actually vim, although I suspect most editors behave this way) will create a new file and change the link to it, but the script still has the original file open. A simple technique that might work is to create a second link to the file before you run the script:
$ ln input-file foo # Create a second link
$ script input-file # Run the script
$ vi input-file # Edit the file
This causes vim to modify its behavior so that it actually updates the file rather than creating a new one.
#user2613272: its either that you have not saved the file before executing it or you are executing some other file with similar name.
as suggested by #bjackfly, i guess you first "cat" your file before execution.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Reading the make's manual page:
`shar'
Create a shell archive (shar file) of the source files.
What is a shar?
It's a shell archive, a self extracting executable shell script which is meant to be a convenient way to ship archives of files and have them appear simply by running the script.
An example is shown in the transcript below which gives only one file from the archive, output.txt:
pax> cat shar.bash
#!/bin/bash
tr '[A-Za-z]' '[N-ZA-Mn-za-m]' >output.txt <<EOF
Uryyb sebz Cnk.
EOF
pax> ./shar.bash
pax> cat output.txt
Hello from Pax.
That's a fairly simplistic one since it only delivers one file, and it doesn't compress it at all, but it should give you the general idea.
A real one would probably give you something like a set of files combined with tar, gzip and uuencode, which would then be passed through uudecode, gunzip and tar to deliver the original content.
A self-extracting archive: a shell script that extracts some data contained in it.
Wikipedia has more: http://en.wikipedia.org/wiki/Shar
It's a kind of self-extracting archive.
It's a bit dangerous (like a self-extracting .exe on Windows), because it runs itself to extract itself, so it could potentially do all kinds of other things that you did not expect.
I think this is what Oracle uses to distribute the JVM on Linux (to make you click through a license agreement first).
Normally, people would just use tar archives (which cannot execute arbitrary code, but also not show any dialogs).
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 10 months ago.
Improve this question
I am debugging a bash shell script, and I am getting this error message:
[[: not found
The line number it points to is the end of my outer do loop.
Any ideas?
Thanks!
Edit: here is the script: https://github.com/stephenh/git-central/blob/master/server/post-receive-hudson
The [[ is used in BASH as a builtin test condition. However, it doesn't work in regular Bourne shell that many systems default to when running things like cronjobs, etc.
Are you putting the shebang (#! /bin/bash) as the first line of your shell scripts? Is this a cronjob? Can you print out the value of $RANDOM (Bash will print out a value, Bourne will not)?
Show us the program that's giving you this problem, and tell us about the system it's running on (Linux? Solaris? Intel? Cygwin?) maybe we can figure it out.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
The very first line of my expect script fails. Here are the entire contents of my script and it fails:
#!/usr/bin/expect -f
And it fails right off the bat with
": no such file or directory
as my response. Expect is in fact installed and is located in /usr/bin/ and I am running this from root. I have no extra spaces or lines before the # sign either. Of course there was more to the script originally but it fails way before it gets to the good stuff.
Tried it and here is the result: /usr/bin/expect^M: bad interpreter
Is it possible that there's a Windows newline (the ^M) in there that's confusing the script? You can try od to see what newline character(s) is after the expect and tofromdos or an editor (e.g. emacs in hexl-mode) to remove it. See the man pages for more info.
I had this issue and found I didn't have the expect interpreter installed! Oddly enough, if you ran the command in the shell it worked. However, through a shell script I got this error:
/usr/bin/expect: bad interpreter: No such file or directory
I fixed it by simply installing the Expect interpreter. The package name that was chosen was: expect libtcl8.6
Just run:
sudo apt-get install expect
Your line endings are wrong. Shove it through dos2unix or tr -d '\r'.
I don't really know expect, to be honest, but when I run that on my system it "works" fine. Nothing happens, but that's what I'd expect. I don't get any error message. According to the man page,
#!/usr/bin/expect -f
is the correct way to start your script. Expect then slurps up the script you are executing as the cmdfile.
The way I got it to reproduce the problem was to actually put a ^M at the end of the line instead of a normal newline (saw Bert F's response and that prompted me to try it). I'm sure vim's :set list command will show any odd characters.
If you observe the error, there was a windows newline character, that is added because its copied from windows machine via mail or winscp. So to avoid this error copy the script using scp linux to linux and execute the script.