run UNIX programs from the working directory? - macos

In order to run UNIX programs from my current directory, I included this in my ~/.profile (I'm using Mac OS 10.9):
export PATH="./:$PATH"
Anything wrong with this approach? It seems obvious, so why isn't it included by default? And, is there any better way to do it?

Don't do it.
Adding . to $PATH is a security risk, that's why it's not like that by default. Consider the paths listed in $PATH as "trusted locations". You can run the programs and scripts in them without typing their absolute paths.
If you add . to $PATH, then you may run things by accident. For example I often run the netstat command to check statistics. I'm so used to it, I type only until "nets" and press tab, and I know it will be auto-completed to "netstat" so I very quickly press enter. If I had . on my $PATH, and there was a malicious script named "netst" in the current directory, then I might accidentally run it when I mean to run netstat as usual, pressing enter too fast to realize that tab auto-completed to netst instead of netstat.
This is just one example, I could easily think of more. Having . on $PATH is a security risk, that's why it's never there by default in any system. Appending . to the end is better than prepending it, but it's really best to not do it at all. Typing the ./ in front of programs should not be too much of a hassle, and you have the peace of mind of knowing exactly what you're running.
I think the conclusions in the duplicate questions are too soft:
https://superuser.com/questions/156582/why-is-not-in-the-path-by-default
https://unix.stackexchange.com/questions/65700/is-it-safe-to-add-to-my-path-how-come
Nobody should ever do this. The convenience this gives is ridiculously small compared to the dangers.

That's a good way to do it if you need it.
One reason it's not included by default is that malicious packages (of any kind, like tgz) can contains programs named the same as system commands that will remove things, start viruses or small daemons for future DDoS attacks.
What if a pack contains a program called emacs or vi? That besides showing the directory or change working directory also does something else?
So before putting that in your path consider what you will download.
Personally I'm happy with running ./local_program instead of putting it on the path.

The dangers of putting . in your $PATH are easy to find in other SO answers, so I'll just concentrate on "is there a better way to do [it]?". If "[it]" is "run my scripts without annoying punctuation," then the better way is to put all of your scripts in a directory called, for example, ~/bin, and add that to your $PATH.
You still need to be careful about what you put into that directory, and you will still have to avoid reusing names of built-ins as executables (test and time are popular bad names), but it doesn't open you up to random exploits or unexpected consequences of typing ls from the wrong directory.

Related

How can we find the original file in case we create several hard links to a file?

Although we don't need it much but still if we want to know the original file, how would we do that?
How can we find the original file in case we create several hard links to a file?
I assume that you are talking about hard links in a POSIX file system.
You can't. As far as the file system is concerned, the hard links are indistinguishable.
OK. Maybe if you created the hard links via a shell, the commands might be in the shell history. Or the information might be in log files. Or possibly audit files ... if auditing is enabled. But not normally.

bash open a vi and then execute a vi register

I am currently trying to make a script that will take any number of arguments and create files for them. I have some registers saved in vi that I already have loaded with generic things I want in each file type.
So, I know that my shell can enter a file by typing vi "filename" but I am wondering if there is a way I could execute a register and then close the file, I suppose I could use my shell to append things I want to but it seems much more tedious which I am happy to do if you guys don't have any hints.
P.S. I have been looking online for way to open multiple tabs in the same terminal with only having generic Ubuntu without having to open a new terminal. But I think the only way to make this possibly happen is through programs I have to install, correct? Thank you for your time.
If you're trying to open files in an already-open execution of vim, then I think that'd have to be two processes:
outside process: to create the files (the one you planned to create)
inside process: (in your already opened vim) to load newly-appeared files (eg: like an automated :e new/file.txt)
wrt your PS: multiple files (buffers) is doable by default; a quickstart:
you can watch or read this screencast more about "buffers"
definitely shouldn't need new software
try this out yourself: vim ./foo ./bar (in a terminal)
:ls to see buffers you've opened (you'll see "foo" and "bar)
:buffer N to jump to one of said buffers
wrt "tabs" -- is that so that you can click? If so, maybe reconsider using vi (but if you're sticking to vi: you can find documentation to get tab-like UI if you really want, and again: no extra software).

Associate Windows directory with program (or treat directory as file)

This is likely not a simple topic - I have researched this to the best of my abilities and realize that it is not supported in any typical fashion.
My goal is to enable something similar to .app files from OSX, where the application, as well as its user data, can exist in the same file. I imagine it would require writing a tool to manage this behaviour, but this question is more about how to achieve this in the Windows OS. I am quite flexible regarding the implementation details, but the more straightforward the behaviour, the better (i.e. avoiding copying or compressing/decompressing entire directories/archives at runtime would be ideal).
Approaches I have considered:
Find a way to get explorer to treat a directory as a file, so that it can be associated. I have found a way to get explorer to treat a directory as a control panel item, I have thus far been unable to find a way to use this to associate a custom program. See the infamous "godmode hack" for Windows (name a directory something to the effect of "GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}"). This one seems the most hopeful, but I'm at wits end trying to find information about creating a new association of this type.
Come up with some kind of archive format which can extract executable information to a temporary directory, launch this executable passing the archive as a commandline parameter. This seems like the ugliest solution, from a performance perspective. I would prefer a different solution if at all possible, one which doesn't involve making duplicates of the program or its data to run.
Find a way to associate a directory directly, though I have found no trace of this being supported in Windows, and I assume this is a dead-end.
Find a way to get an executable to include writeable embedded files. I have been unable to make any headway with this- I even tried a resource hacker approach, but obviously you cannot modify the assembly while its in use.
Tried to make a self-modifying JAR file with Java, but the route I took would add the JDK as a runtime requirement, which seems a bit overkill. Even then, it would be limited to Java, and I'm pretty sure it's not actually supposed to allow that in the first place.
Modify Windows Explorer. I shudder at the amount of work this would take, not to mention the at-best gray area it falls under legally. Perhaps there's a way to extend explorer to achieve this, I'm not sure.
A custom archive file. This seems like the most straightforward way to do it. But it would ideally need to be an archive format that has very little overhead for file I/O. Could even be some kind of virtual disk that gets mounted, but I am imagining that would be pretty heavy.
I would appreciate any insight that anyone has on this topic. I won't go into reasons as they are irrelevant to the question itself- I'm aware it is likely not the most practical solution to anything in particular. Consider it a novel pursuit.
It can be done by application virtualization,
Read this wikipedia page theory:
https://en.wikipedia.org/wiki/Portable_application
https://en.wikipedia.org/wiki/Application_virtualization
And two pages about software:
https://en.wikipedia.org/wiki/VMware_ThinApp
https://en.wikipedia.org/wiki/Turbo_(software)
Windows 7 added the ability for a Desktop.ini file to add/change the folder verbs on a per-folder basis. Using that trick it is possible to create a "folders as applications" style setup.

Why does Powershell search every directory within one's $PATH for a PSConsoleHostReadLine file?

all!
I noticed that Powershell, or more specifically, pasting and tab-completing within Powershell, was a lot slower on my machine after upgrading to v3 from v2. I opened up procmon to see what was going on, only to find out that every attempt to tab-complete or paste anything triggers Powershell to find various permutations of the file provided in the subject. I have some network folders in my $PATH and walking through those folders every time I paste something seems non-ideal.
It seems that this file allows Powershell to behave more like Bash. While this is absolutely FANTASTIC and I'm looking forward to abusing this feature in the very near future, is there any way to configure Powershell such that it only attempts to find this file in one directory?
Thanks!
PSConsoleHostReadLine is actually a function. If PoSH can't find a method, alias, or anything else executable with that name, it falls back to it's default 'cooked' readline with editing, etc.
To redefine it, create a function:
function PSConsoleHostReadline {
[Console]::Readline()
}
As written, this method disables editing, etc. Write your own insane magic to do whatever you wish.
I'm guessing it's searching all the extra locations due to Powershell 3 having "Module Auto Load" which checks for a function in all locations known in the ENV:PSModulePath, and auto-loads the module which contains said method.
This was an oversight in V3. V4 will only search for functions or aliases - it won't search for external exes when looking for PSConsoleHostReadline.
If you're looking for a bash like experience - check out https://github.com/lzybkr/PSReadLine

How to add your application path to the user's shell path?

Is there a way to add your application path to a user's .bash_profile path variable using shell script? Also, what if the user was using a different shell like zsh etc? Is it possible to "universally" add your application path to the user's shell PATH?
Different shells have different syntaxes so there's no real "standard" way.
There are a couple of things you can do.
Install your application confirming to the FHS so that the default paths work. This means that your executables will be (alteast symlinked) in /usr/bin etc.
At the end of your installation routine, spit out a few shells snippets that the user can stick into their shell initialisation scripts so that they can use your application. You can also take this a level further and test the users SHELL variable and insert the appropriate snippet into the correct initialisation file. This might be unwise though. I don't like programs modifying my personal init files. You can support the csh "family" and the bash "family". That should cover most of the cases. People who use more obscure shells will most probably be knowledgeable enough to port the PATH settings anyway.

Resources