If I have an alias
la=ls -a
Can I then define a second alias after this that uses la
ll=la -l
I can't seem to get this to work with cmder (a Windows terminal emulator), which really just packages clink, ConEmu and some other stuff.
AFAIK you can't use nested aliases for cmd.exe.
However, you may create simple batch files, and one batch may call others.
Aliases work differently in different shells. In cmder you may define aliases in two ways:
Environment page in ConEmu settings
cmder's self-implemented alias.bat.
In any case, these console aliases are intended to be expanded by cmd.exe only, and you may see current list of defined aliases by executing in cmd.exe prompt
doskey /macros
Related
I am interested in any IDE (or even a script) that is capable of refactoring Go source code for variable renaming. For example in Eclipse for Java, one can select a variable, an object or a class, then to rename it and it gets automatically renamed in all the files in the project. This feature is very useful if automatic string replacement may cause substring collisions.
If you're interested in a script, use gofmt with -r flag. Like this:
gofmt -w -r 'OldFoo -> Foo' foopackage
From the docs:
Without an explicit path, it processes the standard input. Given a file, it operates on that file; given a directory, it operates on all .go files in that directory, recursively. (Files starting with a period are ignored.) By default, gofmt prints the reformatted sources to standard output.
EDIT: Today there are better tools for that: gorename for renaming and eg for general refactoring.
The gorename tool performs precise type-safe renaming of identifiers in Go source code.
I'm writing a custom check for installed libraries in autoconf:
AC_DEFUN([AC_GHC_PKG_CHECK],[
...
GHC_PKG_RESULT=$($PYTHON autotools/check-ghc-version-range ....)
...
])
where my Python script that actually performs the check resides in the autotools/ sub-directory of the project.
However, this is not portable, for example make dist-check fails because then autoconf tools are called from a different directory. How can I reference the absolute path to my Python script so that it gets called properly no matter what the current directory is?
ac_top_srcdir or ac_abs_top_srcdir should work in this case:
AC_DEFUN([AC_GHC_PKG_CHECK],[
...
GHC_PKG_RESULT=$($PYTHON $ac_top_srcdir/autotools/check-ghc-version-range ....)
...
])
EDIT: I don't think this approach will work -- it seems that $ac_top_srcdir aren't evaluated until later (AC_OUTPUT?).
What I think might work in this instance is to do something similar to what the runtime C tests do: blast a configuration test to a temporary file (conftest.py instead of conftest.c in this case) and run it. Unfortunately, there's (yet) no builtin macros or for automake/autoconf other tools that directly assist with this task.
Fortunately it seems that a clever person has written at least a couple different ways to do this. The first one is GNU pyconfigure which seems to have facilities for writing Python test code as I described above. The second one is more of an ad hoc macro collection that he used for his project.
You can use $srcdir.
It's not necessarily an absolute path, but it's a path that points from the top of the build tree to the top of the source tree.
I'm trying to get a COTS compiler/linker suite working with CMake and for the most part everything is working well. The issue I am running into is with the librarian.
A typical call as defined in COMPILER-${lang}.cmake file would look like this:
SET(CMAKE_C_CREATE_STATIC_LIBRARY " -v -c ")
but the librarian has no specific way of being told where the object files are so I would like to prepend the object files with the binary directory so as to give the librarian a specific place to find them. However I can't come up with the right syntax to do so.
Any thoughts on how one would do this?
After much work with the compiler/linker suite, it was determined that the main problem was that the compiler did not have the ability of being told where to put the object directly - in essence it did not support the typical -o parameter.
This resulted in the compiler naming the output file whatever it wanted and not paying attention to the that was being passed to it by the make utility.
It also turns out that the main compiler executable was really just a wrapper for the preprocessor, code generator and assembler so I ended up just RE'ing it and building my own wrapper that did support the -o parameter. It was definitively easier doing that trying to get CMake to work with this non-standard approach to generating outputs. Once the compiler started supporting the -o parameter the librarian worked without any issues.
I'm writing a command-line utility in Go that (as part of its operation) needs to get a password from the user. There's a great gopass module for Unix that does this, and I know how to write one for the Windows console. The problem is that the Windows module obviously won't build on *nix, and the *nix version won't build on Windows. Since Go lacks any preprocessor support (as far as I can tell), I have absolutely no idea what the right way to approach this is. I know it's possible, since Go itself must do this for its own libraries, but the tooling I'm used to (conditional imports/preprocessors/etc.) seems to be missing.
Go has build constraints, which can either be specified as comments in a .go file, or as part of the file name.
One set of constraints is for target operating system, so you can have one file for Windows, one for e.g. Linux and implement the same function in two different ways in the two.
More information on build constraints are at http://golang.org/pkg/go/build/#hdr-Build_Constraints
More as a curiosity, if I want to prevent some code from looking at the parent directory (contained in a list of files/directories) and I do something along the lines of (e.g. Perl) next if /^.+$/ to exclude . and .. , is this sufficiently cross-platform? If not, which platforms are different and how might one prevent accessing the parent in that case?
It will work in most modern platforms. (It will also exclude Unix hidden files/directories, but this is probably a good thing given the context.) Windows has a special case at the root of a drive, but it's not so much "different syntax" as "not there in any syntax"; if you have any intention of using platforms such as OpenVMS or Z/OS, it won't work at all.
Note that Perl and Python ship with cross-platform path utilities that you should use instead. I couldn't tell you about PHP or Ruby but I presume both also do so.
Doesn't work in ZX Spectrum. :)
Seriously, pretty much all platforms in current wide use (i.e. MSDOS, Windows, *NIX including Linux) conform to that. Be aware you will also be excluding hidden directories in UNIX-like systems.