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
Related
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.
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.
I've developed a GUI for some build scripts, and am now in the process of deploying it. As the script will be deployed to a number of different machines at various points, I need to use the standard format of directories that the team use.
The GUI consists of a ".fig" file that contains the visual definition of the UI, and a m-script that defines the functionality. I need to locate these two in "fig/" and "m/" folders respectively, but I can't figure out how to. I first searched for an include statement of some kind in the m-script, as when I Run it on its own, the error message in the command window states that the ".fig" file can't be found, but there doesn't seem to be a reference to the ".fig" file anywhere, I assume that it's inferred as both files have the same name but a different extension.
I fear that Matlab's GUI system requires that both ".m" and ".fig" files are in the same location, but this will be an inelegant solution that I'd rather not go for if I can avoid it.
The next thing I'm going to try is to call a script that copies the fig file from the other directory to the same location as the m-script, when it is executed, then deletes that copy once the script exits, which again seems a clunky solution, but will allow me to adhere to the team's organisation conventions.
Does anyone else know of an undocumented means of specifying the relative location of a GUI ".fig" file?
You can export the GUIDE-generated GUI as a single .m file. Check out this blog post: GUIDE GUIs in All One File.
I'm not sure if this is a new feature, or one of those things that has always been there...
I needed a little script to read data out of windows-style .ini files. Searching my windows machine I found inifile.rb in this path:
C:\ruby\lib\ruby\site_ruby\1.8\vr\contrib\
it seems unnatural to add this path directly to my rubylib path as this will mean any other special units I want will need to be added.
so in my code I wrote this:
require 'vr/contrib/inifile'
ini = Inifile.new("file.ini")
puts ini.read("common","name","default name")
This worked, but also doesn't seem elegant for inclusion. There must be a better way to specify this in the code ?
I think inifile.rb is part of vruby, which, it appears, is "a GUI library on MS Windows for Ruby". Which is something I'd never come across, so thanks!
It looks like that path is going to be necessary unless you either add it to your main Windows PATH (possible overkill) or to your Ruby load path, which you can access via the slightly arcane $:
I hope that , if only perhaps a little...
I have a VisualStudio project with a few sub folders like Accounting, Store etc. I need to make a duplicate of the "Accounting" folder and also rename all the Class Objects in that folder. Each object in that folder is prefixed with "Accounting".
Basically I want to name the duplicate "Customer" and change all the prefix of the Class Objects to Customer..
What's the fastest way in doing this?
The fastest way to do this is probably the Unix command line tools. (On Windows, you can install, e.g., MSys or Cygwin to use them.) If you haven't done this, however, it will take quite a while to set this up and get familiar with them.
Here on my Windows box I would probably use a combination of TotalCommander (for file copying and batch file renaming) and VS itself (for batch identifier replacement).
I have, however, never come into the situation to do this, since, in general, I shy away from code duplication. Have you asked yourself why you're doing this and whether there's a better way? If the code duplication is so massive that it's worth the time asking us how to do it the fastest way, this isn't just a code smell. That's a dead skunk decaying under your pillow.
I'd suggest that you copy the folders using Windows Explorer and use a tool like notepad++ or TextPad to rename multiple files.
You can use a macro to rename the classes and the file names. If the solution is bound to Visual Source Safe, it will pickup the file rename. More info and code example on http://tseonet.blogspot.com/2010/12/using-macros-in-visual-studio-to-rename.html.