I am not root. I have written and placed a script in the cgi-bin of my apache server. The code is too long for here, but in a nutshell, the script is called from a browser and a filename argument is also passed as a URL parameter. The script takes the filename, locates the file and reads it. The file contains a simple list of files/locations to be copied. The script iterates through each line of the file and copies the file on that line from the current server to a remote server using ssh and standard rsync commands. It's all pretty standard stuff.
The script runs perfectly from command line, all files are copied correctly. When launched from the browser, the script appears to function perfectly. It throws no errors and debug logs tell me everything was copied fine, only the actual files themselves are not actually copied.
I'm assuming it has something to do with the script being run by apache (or wwwroot) in the cgi-bin, which is not the script owner, as I am. As I am not root, I cannot change ownership or use sudo. Any ideas on getting this to work?
Related
I have a .cmm file which helps in debugging of Qcomm chipsets.
This file has a line : cd ../../../../../modem_proc
When I run this same cmm file using T32 GUI, it runs fine and does the work. But when I am trying to run the same file using windows command line using,
C:\T32\bin\windows64>t32mqdsp6.exe -c C:\T32\config.t32 -s D:\path\to\xxx.cmm
Following error is thrown in T32: syntax error in B::cd ../../../../../modem_proc
What am I missing here? I have no hands-on experience with T32 what-so-ever.
The problem probably results from different working directories. Type
PRINT OS.PWD()
in the GUI and add it to the top of the script. I'd suspect they are different.
Don't use working directory relative paths, instead use paths relative to the script, e.g.
CD ~~~~/../../../../modem_proc
The four tilde (~) symbols mean "directory of the currently executed script". There's still a possible issue with this solution when using multiple GUIs and the intercom, but for most use-cases this should be OK.
When starting TRACE32 (up to build 99518) without option "-s", it starts a default script t32.cmm form your TRACE32 installation directory. But t32.cmm is not executed, when "-s" is used.
So probably your t32.cmm is changing your working directory. If so you can fix the issue by adding the line
DO ~~/t32.cmm
to the top of your script xxx.cmm.
See also https://www.lauterbach.com/frames.html?help_autostart.html
The default working path is also set by the TRACE32 configuration file. That is the file passed with "-c". So if your are using a different configuration file than C:\T32\config.t32 when starting your TRACE32 GUI the normal way, then you should use that configuration file also when starting TRACE32 from the command line.
To get the path of the configuration file usually used, start TRACE32, execute command AREAand then command PRINT OS.PCF()
Furthermore dev15 is probably right here https://stackoverflow.com/a/53671657/4727717:
Use paths relative to the PRACTICE script (cmm-file) by starting each path with four tildes.
I am having the following problem:
When I want to run an uncompiled Lua script in Apache, I just add #!/usr/share/lua at the beginning of the file, so far everything works fine.
But if I want to compile it with luac to have it run a bit faster I cannot add any text to the file, as it is compiled binary data (which still needs to be interpreted by the Lua interpreter, and cannot be executed on its own).
Is there a way to tell Apache to always have /usr/share/lua interpret files with the .lua (or .luac to mark them as compiled) extension?
I'm not aware of a way to do this as a CGI script, as the CGI spec basically requires that the shell can figure out how to run a file based on the hashbang at the beginning.
However, you could write a simple CGI handler in Lua that does a loadfile() on the .luac file and then executes it. You can set .luac files to be handled by this script with the following directives in a .htaccess or httpd.conf file:
# Files of a particular file extension
AddHandler my-file-type .xyz
Action my-file-type /cgi-bin/program.cgi
In this example from the docs, program.cgi would be passed the filename requested by the URL so you could parse it and run that file.
I put my LINQPAD.config in the same folder as LINQPad.exe and it works well for LinqPad GUI.
When I run the same .linq program via lprun.exe. lprun.exe does not use the same LINQPAD.config file as LINQPad.exe but instead it expects a LINQPAD.config file in the same directory as the .linq file which is passed as an argument to lprun.exe.
This is quite inconvenient. Now, I have two options, either copy LINQPAD.config to where my .linq script is or copy my .linq script to where lprun.exe is.
lprun.exe's help doesn't mention anything about specifying a path to LINQPAD.config.
This is a bug and will be fixed for the next LINQPad 5 release (5.0.10). It should pick up the config file from the query folder only if it exists, otherwise it should fall back to the lprun.exe folder.
I am using a Script Task in SSIS. So I am writing in vb.net. I have a substantial amount of code that ends up writing two files: one is a .bat file with this EXACT contents in it, minus I've changed hostname, username, and password of course:
C:\Users\ipisors\AppData\Local\Temp\091014121929_Phoenix\psftp.exe -pw PASSWORD -b C:\Users\ipisors\AppData\Local\Temp\091014121929_Phoenix\091014121929.txt USERNAME#HOST
(I'm sure it has this, because I manually check it after the Script Task runs).
The content of the .txt file referenced in the command is this EXACTLY:
cd uploads
cd OUT
mget PhoenixEnrollment_20140910*.txt
bye
MY QUESTION -
After the script task runs successfully, there is no downloaded file inside the directory of PSFTP.EXE (C:\Users\ipisors\AppData\Local\Temp\091014121929_Phoenix). Nothing.
However, if I manually double click on that same batch file that the script task was supposed to SHELL(), it immediately works perfectly. Within a few seconds, there is a downloaded file inside C:\Users\ipisors\AppData\Local\Temp\091014121929_Phoenix
What could possibly be the difference in reaction from the FTP server, between my script task code:
Shell(strBatPhoenix, AppWinStyle.NormalFocus, True)
(which by the way - yes I can actually see it working!)
and double clicking the same da*n file
I've also debugged the script task, it's definition Shelling out the EXACT SAME bat file.
Help please!
I will say the password to the SFTP site has a caret (^) in it, which I am escaping by using a double caret.
Figured it out after additionally testing one other way:
I used the command prompt itself to run my batch file. It ALSO did not download to the expected directory. I began to suspect that, even though the Shell was automating a batch file in the 'desired' folder......that batch file was then reading the 'local' directory as whatever calling application had initially Shelled it out.
In this case: c:\users\myusername. And therein was my file.
Lesson to be learned: Shelling a batch file, even if that batch file shells another file, may end up with one application or another reading your instant directory as the instant directory of the application that did the first shell, not the last shell.
I am trying to zip the contents of a Folder in SSIS, there are files and folders in the source folder and I need to zip them all individually. I can get the files to zip fine my problem is the folders.
I have to use 7.zip to create the zipped packages.
Can anyone point me to a good tutorial. I haven't been able to implement any of the samples that I have found.
Thanks
This is how I have configured it.
Its easy to configure but the trick is in constructing the Arguments. Though you see the Arguments as static in the screenshot, its actually coming from a variable and that variable is set in the Arguments expression of Execute Process Task.
I presume you will have this Execute Process task in a For Each File Ennumerator with Traverse SubFolders checked.
Once you have this basic setup in place, all you need to do is work on building the arguments to do the zipping, how you want them. A good place to find all the command line arguments is here.
Finally, the only issue I ran into was not providing a working directory in the command line arguments for 7zip. The package used to run fine on my dev environment but used to fail when running on the server via a SQL job. This was because 7zip didn't have access to the 'Temp' folder on the SQL Server, which it uses by default as the 'working directory'. I got round this problem by specifying the 'working directory as follows at the end of the command line arguments, using the -ws switch:
For e.g:
a -t7z DestinationFile.7z SourceFile -wS:YourTempDirectoryToWhichTheSQLAgentHasRights