I have written a script that writes multiple file paths to stdout. (one path per line)
eg.
C:\Users\user\Documents\someFolder1\foo.txt
C:\Users\user\Documents\someFolder2\someSubFolder\bar.jpeg
C:\Users\user\Documents\someFolder3\baz.docx
Ideally I would like to pipe those file paths into Windows File Explorer so that non-technical users can interact with them in a familiar way. (previews, contexts menus, sorting, double-click to open, etc.) But really any file browser with a GUI and similar functionality would do.
I am also interested in ways to solve the same problem on Linux and macOS
Related
My question is not about how to run the scripts with double click!
I'm curious about the reason of such behavior.
The .bat, .cmd, .vbs, .exe, and many others runs with the double-click, but .ps1 not, why?
The reason to associate .ps1 with Notepad is about security.
Back in the days, Microsoft got burned really bad because of associations' default actions. Per default, Windows' file manager (later known as File Explorer) aimed at easy usage. It didn't show file extensions. That is, MyResume.doc was shown in the default Explorer list as simply MyResume - and it often had a Word icon too.
While this was convenient a way to save screen real estate, it offered a wonderful way to exploit systems. A lot of users simply double-clicked files based on their names and icons. Now, crackers started to send around files that had double extension like MyResume.doc.vbs. Explorer's default action was to strip the .vbs, which meant that the file actually was Visual Basic Scripting file. Since Windows associated .vbs to Windows Scripting Host, the script file was executed with user permissions. To prevent this attack vector, Powershell files are not associated with powershell.exe per default.
Famous cases of extension exploits are the love letter ILOVEYOU and promise of adult content about Anna Kournikova.
Another can of worms (sorry for the horrible pun) are Windows screen saver files. The .scr files are really just executables. A lot of users were fooled to install backdoors to systems, as they didn't understand risks of installing screensavers. This was further exploited by sending files that had extensions not matching the payload, and relying that OS still picked the proper application association.
I split my terminal so I have two prompts open (specifically kitty) I resize one of them so one is large where I use my file browser (ranger) and run commands in the smaller one.
My goal is to have the working directory in sync between these two splits, that is, if I change directory in one of them, the other also changes directory.
I asked on IRC and they said that the two shells are completely independent processes and that I would have to write a complicated program to get this to work.
Could someone outline what I would need to learn to make a program like this?
You would probably need something to interact with an inter-process call, that sent a message from your active prompt to the passive so passive knows to change its working directory.
Further more, you need to go deep into shell source code and find out how to make a change in working directory.
Can anyone explain to me, how applications usually communicate if one application has to send data to a second application. (an image for example). Or how can i find out how the communication is implemented?
In my example, i am trying to find out how "Capture One 11.x" is opening images with other applications (like photoshop or lightroom).
I was guessing, that "Capture One 11.x" will open images inside other applications by running the second application with additional start parameters (like the filepath of the opened image). But i can't find any evidence for this behaviour.
I am thankfull for any hint or help.
There are numerous ways applications can communicate with one another. Through temp files, pipes, sockets, etc.
Your specific question sounds like it boils down to "What is one way to have application A open file B in application C".
This is pretty easily achievable from the command line, for example, using the macOS command open with -a to choose the application.
open -a Adobe\ Photoshop file.jpg
or
open -a TextEdit file.txt
open -a MacVim file.txt
So, one very rudimentary way an application could open a file in another specific application would be to make a system call to macOS open.
I have a build script where i create a text report file and output various log type stuff to it. The data is all being built onto an external hd which (according to 'mount') has file format "fuseblk" (which i've never heard of).
The building all seems to work ok but my report files are being saved as executables, which linux interprets as SOR files. I'd like them to just be regular text files, openable by default in my regular text editor.
I'm making the file, and writing to it, like this:
#report = File.open(File.join(DESTINATION_BUILD_FOLDER, "#{title.folder_name}_report.txt"),"w")
...
s = "making modules folder inside resource_library folder";puts s; #report.puts s
...
#report.close
I've done this lots of times before and never encountered this problem. Any ideas anyone?
cheers, max
ps i know that i can edit the saved files to make them non-executable, my question is 'why is this happening in the first place?'. Cheers :)
I don't think there's anything wrong with your program. The fuseblk just means it's being mounted through FUSE, which allows filesystem drivers to run as userspace programs, instead of kernel modules. Most likely, the filesystem is NTFS or FAT32.
The problem here is that Linux is assuming everything on the drive has the execute bit set. This is because neither NTFS nor FAT32 have the capability to store Linux permission bits (NTFS has a very different permissions system, FAT32 has virtually none). And I bet you're trying to double-click on the log files in something like the gnome file explorer, right?
Well, go there with the command line and use less or your favorite command-line editor to view them. Or right click on them in the file explorer, or open them with File -> Open from a text editor. If you ask your question to people who know Gnome (or KDE?) better, you'll probably get a better answer.
I am trying to copy C source files from a vms alpha to a windows machine to allow easier editing of the code. (VMS editor is just a text editor and it would be nice to have syntax highlighting etc)
I can copy this across using Exceed FTP and this handles the issue of duplicate filenames with version suffix that vms has:
File.c;1
File.c;2
Flle.c;3
But when I open a file I've transferred, all the line breaks have been lost and the entire file is just one line.
Can anyone recommend a solution to this or offer any hints?
Thanks in advance
ps. I need to be able to copy the files back to vms and still maintain format.
It may be off interest by now, but in case you still wonder about "one-line" text files after FTP transfer.
The short answer: force the FTP transfer mode to ASCII (or text) in your FTP client. This will make sure that the C-files you transferring (in fac all files) are treated as text, otherwise they're assumed to be binary, so you get a byte-stream.
Long answer: There're 2 FTP transfer modes: ASCII/text and binary/image. The default is sometimes clent or server-specific.
Many clients have Auto-mode that interprets the file extension to set the proper transfer mode (.TXT,.CSV etc..)
When you access the VMS server via FTP client, too often the [Win-based] client is not VMS friendy, so it does not parse the file-list properly. Thus it gets confused by version number appended to the "usual" file-name:
filename.ext;ver ==> file.c;1
So instead of seeing .C (and assuming text), it sees .C;1 and thinks it's binary.
I use Filezilla FTP client to/from VMS and so far it does it properly (though version-support is not as I'd sometimes like).
Copying a file to and from your windows desktop every time you want to edit gets old very quickly.
You may be able to implement a much nicer alternative. There is some software under VMS that permits a VMS directory tree to be treated as a "network disk" under windows. Once you've set it up, and set up your windows to recognize the network disk, you can just open the file with a windows text editor without moving it from VMS to windows. You can also browse the directory tree, which appears like a tree of folders.
When you issue a save from your text editor, the saved copy supercedes the previous version over in VMS land. And it mediates correctly between RMS format and embedded newline format. It's a whole lot more convenient than FTP, for this purpose.
After doing a quick Google search, I think the name of the VMS software is PATHWORKS. But I'm not sure.
A few points I have on this
PATHWORKS is fairly old and (as far as I recall - I dont use it) doesnt work well with recent windows versions, such as supporting Active Directory. Within the last few years HP have ported SAMBA to VMS and this is the way to go if you want to make areas of disk visible to windows machines. Should be easyt to find on HP web site.
If you want to try the FTP/SFTP route I would try SFTP and go for VMS version of at least 8.2. TheTCPIP suite was rewritten (or reported from a Unix version) at this point.
VMS supports a number of formats for text files. As well as the complex record structure described above, there is STREAM_LF which is the same as a unix file and STREAM_CRLF
I found some interesting information about OpenVMS text file structure. That corresponds with a vague memory I have of how VMS handles text files; they're not stored as streams of bytes like Windows and Unix systems, but as a sequence of records (each record is a text line). Records can be either fixed width or variable width. Whatever reads the file is responsible for the "paper control", what we normally call newlines these days.
You might check the options in Exceed FTP to make sure that you're transferring the file in an appropriate ASCII mode. There might be special options you need to set on the FTP server to read and write the files in the appropriate mode too.
I'm no expert - let's get that out and in the open ;)
I have been having similar problems in FTPing files from OVMS Alphaserver to Win7 desktop so I can migrate to SQL.
FTP [Attachmate & WIn CLI] workled fine under WinNT.
I suspect Win7 does not like the name.ext;version format of the OVMS file.
Filezilla - doesn't work.
PuTTY - doesn't work
Window CLI FTP - doesn't work [partial file transfer; times out & truncates file].
Using Attachmate's "Reflections for the Web 2011" to emulate Vax terminal - works fine.
Think I'll have to go back to Attachmate for assistance but partially hamstrung by our [Australian Fed Govt] IT services which has the final say
Some editors, such as BBEdit on the Mac, support directly opening/saving files via FTP/SFTP/etc. (BBEdit also supports various different line endings as used on different platforms, which would help with your other problem). I expect there must be a Windows editor with similar functionality - my Windows-using colleagues all rave about something called CodeWrite (or CodeWright ?) so I guess I would take a look at something like that.