I am trying to write a script that automates other perl scripts. Essentially, I have a few scripts that rollup data for me and need to be run weekly. I also have a couple that need to be run on the weekend to check things and email me if there is a problem. I have the email worked out and everything but the automation. Judging by an internet search, it seems as though using Proc::Background is the way to go. I tried writing a very basic script to test it and can't quite figure it out. I am pretty new to Perl and have never automated anything before (other than through windows task scheduler), so I really don't understand what the code is saying.
My code:
use Proc::Background;
$command = "C:/strawberry/runDir/SendMail.pl";
my $proc1 = Proc::Background -> new($command);
I receive an error that says no executable program located at C:... Can someone explain to me what exactly the code (Proc::Background) is doing? I will then at least have a better idea of how to accomplish my task and debug in the future. Thanks.
I did notice on Proc::Background's documentation the following:
The Win32::Process module is always used to spawn background processes
on the Win32 platform. This module always takes a single string
argument containing the executable's name and any option arguments.
In addition, it requires that the absolute path to the executable is
also passed to it. If only a single argument is passed to new, then
it is split on whitespace into an array and the first element of the
split array is used at the executable's name. If multiple arguments
are passed to new, then the first element is used as the executable's
name.
So, it looks like it requires an executable, which a Perl script would not be, but "perl.exe" would be.
I typically specify the "perl.exe" in my Windows tasks as well:
C:\dwimperl\perl\bin\perl.exe "C:\Dropbox\Programming\Perl\mccabe.pl"
Related
As soon as I try to access a folder/file containing an emoji in its name from my Lua 5.2 script, for example like this:
os.execute('start "" "' .. path .. "\\scripts\\menu\\📄 My Scripts" .. '"')
The Windows' Command Prompt simply refuses to open it with the following error message:
I'm aware Windows' Command Prompt doesn't support emojis and therefore is not possible to make it work just like that, but my doubt is if won't exist some workaround or whatever I can do to ensure any Windows/Unix user is going to able to get the folder open by my Lua script without any problem.
I have tried i.e. things like use the codes instead (1246 and U+1F4F0 in this page facing up case) without success. Couldn't I for example simply use some kind of "wildcard" instead? I mean, knowing it's always going to be the very first character in the name. Or, well, any other ideas will be welcomed, cause nothing I'm trying really seems to work...
Of course if it's going to represent any problem I'll simply refuse to use them, but it came in handy for some "first sight" folder distinction and, if possible, I'd like to can count this little visual resource 🙄
This is a Problem about how the string is constructed.
I found only one solution with [[command "path"]] (on Windows 11 and Lua 5.3)...
os.execute([[start ]] .. path .. [["\scripts\menu\📄 My Scripts"]])
-- My Testpath is/was: os.execute([[dir "%localappdata%\nvim\📄 Lua"]])
...the long string ([[]]) will not be interpreted (coercionated) by Lua.
That also have the side effect that you can use single backslashs with that kind of string.
Environment variable expansion (e.g. Windows: %localappdata%) only works inside doublequotes.
Single quotes instead ([[command '%localappdate%\path\']]) will not work (expanded).
os.execute accepts only ANSI-encoded strings (win-1252 in European Windows), but it is unable to encode an emoji.
Hint: you can create .bat-file to do the task for you and invoke it from Lua with os.execute.
I just want to be able to run a python script from the interpreter, so that I can work on my changes to my script in notepad or other editor, save, and then interactively test changed code in the python interpreter.
Also, IDLE is not a solution. I'm operating on a government computer that is blocking the port it uses to communicate interaction between console and module.
To clear up any confusion, here's a demonstration of what I'm trying to do:
So, how do I do it?
EDIT:
Okay so I found a statement that does what I want. exec(open('dir').read()). The problem I think is that the directory I want to refer to contains periods. But I'm sure this will work, because open('dir').read() produces a string of the contents of a document specified, as long as I reference the likes of C:\myTest.py, and exec() obviously runs strings as input. So how can I reference files from the location I want?
Okay so the problem seems to be that Windows addresses often contain what python sees as 'unicode exits'. I'm not sure what they do or how they work, but I know they start with \ and are followed by a single letter and that there are enough of them to use up half the alphabet. There are a few solutions but only one is worth a damn for this application. I came across an operator that can be used in conjunction with strings, similarly to how + can be used to concatenate multiple strings, it seems r or R if you prefer (interestingly), can be used immediately before a string to tell the interpreter to take the string 'literally' as a string, and nothing else.
One would think that the quotes would be enough to express this, but they aren't and I'll probably eventually find out why. But for now, here's the answer to my question. I hope someone else finds it useful:
In plain text: >>> exec(open(R'C:\Users\First.Last\Desktop\myScript.py').read())
Is there any way of adding "helper" methods to the mongo shell that loads each time you use it?
Basically whenever you want to query by _id, you have to do something like this.
db.collectionName.findOne({_id: ObjectId('THIS-IS-AN-OBJECTID')})
Whenever I'm going to be doing a lot of command line commands, I alias the ObjectId function to make it easier to type.
var ob = ObjectId;
db.collectionName.findOne({_id: ob('AN-OBJECTID')})
db.collectionName.findOne({_id: ob('ANOTHER-ONE')})
db.collectionName.findOne({_id: ob('ANOTHER')})
It would be pretty chill if there was a way of either running a specified piece of JS / add a chunk of code that runs each time mongo is pulled up from the shell. I checked out MongoDB's CLI documentation, but didn't see anything like that available, so I figured I would ask here.
I know there is a possibility of using this nefariously, so this might be a situation where it might be unsupported by the mongo shell by default. This might be a situation where we can create a helper bash script of some sort to launch the shell, then inject keyboard input to create the helper ob function? Not sure how this could be tackled personally, but would love some insight on how to do something like this, either natively or through a helper script of some sort.
If you want code to execute every time you launch the shell, then whatever you place in .mongorc.js will be run on launch:
.mongorc.js File
When starting, mongo checks the user’s HOME directory for a JavaScript file named .mongorc.js. If found, mongo interprets the content of .mongorc.js before displaying the prompt for the first time. If you use the shell to evaluate a JavaScript file or expression, either by using the --eval option on the command line or by specifying a .js file to mongo, mongo will read the .mongorc.js file after the JavaScript has finished processing. You can prevent .mongorc.js from being loaded by using the --norc option.
So simply define your variable association there.
You could also supply a file of your choice along with the --shell option to let the command know you want the shell opened on completion of any instructions contained:
mongo --shell file_with_javascript.js
But as mentioned, the .mongorc.js file would still be called (if present) unless the --norc option was also specified.
I must work with tcsh.
I am using an internal tool that provides basic completion for some of its commands.
I would like to extend the completion.
I mean that in future releases the default completion may evolve.
I tried something like this:
set def_cmpl = complete tool
complete tool $def_cmpl 'n/-l/(reg short long gui)/'
But I don't understand the result I get.
Indeed, the quotes inside $def_cmpl are doubled:
tcsh> complete tool
''n#-t#$script#'' n/-l/(reg short long gui)/'
I tried some tricks with echo, sed, etc. but I can't avoid those ''.
Could somebody help me?
Please don't say go on bash... The tool doesn't support it...
Finally, I did not find a solution to keep the data inside the script. So, the solution was to redirect the output of the complete command inside a file and then to append new lines to the file.
ruby somescript.rb somehugelonglistoftextforprocessing
is this a bad idea? rather should i create a separate flat file containig the somehugelonglistoftextforprocessing, and let somescript.rb read it ?
does it matter if the script argument is very very long text(1KB~300KB) ? what are some problems that can arise if any.
As long as the limits of your command-line handling code (e.g., bash or ruby itself) are not exceeded, you should have no technical problems in doing this.
Whether it's a good idea is another matter. Do you really want to have to type in a couple of hundred kilobytes every single time you run your program? Do you want to have to remember to put quotes around your data if it contains spaces?
There are a number of ways I've seen this handled which you may want to consider (this list is by no means exhaustive):
Change your code so that, if there's no arguments, read the information from standard input - this will allow you to do either
ruby somescript.rb myData
or
ruby somescript.rb <myFile.txt.
Use a special character to indicate file input (I've seen # used in this way). So,
ruby somescript.rb myData
would use the data supplied on the command line whilst
ruby somescript.rb #myFile.txt
would get the data from the file.
My advice would be to use the file-based method for that size of data and allow an argument to be used if specified. This covers both possible scenarios:
Lots of data, put it in a file so you won't have to retype it every time you want to run your command.
Not much data, allow it to be passed as an argument so that you don't have to create a file for something that's easier to type in on the command line.