I want create a hidden ini file under macosX environment with Firemonkey (XE3).
But unfortunaly this command is not known anymore in system.utilys
Somebody tips?
On a Mac, there are two ways to make file "hidden" or "invisible".
Like Linux or Unix, you can start the filename with a dot (.).
You can also use the setfile tool that ships with Xcode to set attributes to make it invisible ([setfile a -V filename][3]).
Depending on the way, you will have to replace the Win32 specific SetFileAttr call with a Mac specific rename, or find out which API setfile uses to set the attributes.
In UNIX (and in this layer Mac OS is largely spin-off from FreeBSD) there is no "hidden" flag on file, instead special files should have their name started with dot. http://en.wikipedia.org/wiki/Dot-file
So if you want to hide a file - rename it.
That is not the question about Delphi = that is the question of operating system, Windows vs UNIX.
Open console/terminal/whatever they call command prompt in Apple, go to ur home folder and issue two commands: ls and ls -a - compare the file lists in output.
Well, for starters you can do it in Linux - http://bellard.org/jslinux/ - wait few seconds for it to boot, then issue ls, ls -l, ls -a, ls -la and see the difference.
Dot-files are treated specially and hidden by default.
Related
I'm currently practicing basic Shell Commands in WSL, Windows Subsystem for Linux (I do not have a linux system but I want to get familiar with commands).
I start a bash session on the command prompt window and navigate to my desktop using cd . In desktop I noticed that after using ls -lF some files with the prefix ~$ appear, such as: '~$executable.x'* or '~$file.txt'
These files are not currently present under the desktop directory, but I was able to remember that they were at one point (varying from a week to months ago).
When I do the same process in powershell windows (not using linux commands) I noticed that files displayed match the desktop and no extra files are listed.
I was wondering if anyone could explain what ~$ means in this context? my intuition is telling me they are backed up files that are somehow hidden in the desktop. After googling, all I could find is that ~ reefers to the home. I also understand that $ is the default prompt symbol for the bash shell when it is waiting for me to type something, but I'm still confused on why it would show up as a prefix for the name of a file.
Hope I made my question clear.
I'm currently reading "Linux® Command Line and Shell Scripting BIBLE" by Blum and Bresnahan but I could not find an answer there, this is my last resource after many googling attempts. Any other source for more information on the topic would be helpful.
On Windows, files that start with ~ are used for hidden files. More specifically,, the prefix ~$ are often used as backups for programs, should they crash before writing updates to a file (e.g. Microsoft Word, etc.)
From Wikipedia:
The tilde symbol is used to prefix hidden temporary files that are created when a document is opened in Windows. For example, when you open a Word document called “Document1.doc,” a file called “~$cument1.doc” is created in the same directory. This file contains information about which user has the file open, to prevent multiple users from attempting to change a document at the same time.
See: Why does Word make temporary files?
Relevant superuser question: https://superuser.com/questions/405257/what-type-of-file-is-file
I've tried runemacs --user d:\path\to\init\.emacs but it gives
Error (initialization): Invalid user name d:\path\to\init\.emacs
I mean custom file in custom location like on my pendrive etc. and not in my default locations in user folder. I try to create a cmd files with corresponding inits for different configuration.
I am guessing that your end goal is to run Emacs from a USB drive which you can carry around. There are two ways to have Emacs start with a different init file:
(1) the -q --load way
This is simply to run
emacs -q --load path-to-your-init.el
which starts Emacs without any initialization, then loads path-to-your-init.el
Gotchas of this way: in this case, Emacs doesn't really consider the el file to be an init file, in fact, Emacs hasn't gone through initialization at all, which means the following post-initialization steps are skipped:
enabling packages, that is, evaluating (package-initialize)
running hook after-init-hook, that is, evaluating (run-hooks after-init-hook)
You may have to add post-initialization stuff in your alternate init file.
Also, Customize interface won't let you save settings if Emacs is started with -q option.
(2) the HOME way
Create my-emacs.bat with contents:
set HOME=%~dp0
C:\path-to-your\Emacs\bin\runemacs.exe --xrm "emacs.Background: light green"
When you click on that bat file, Emacs creates folder named .emacs.d not in your usual user directory, but in where the bat file is. You can put your own init.el in that .emacs.d folder. With this Emacs, evaluating (find-file "~/.emacs.d/init.el") opens your own portable init.el and not the init file in your usual user directory. You may want to delete the --xrm "emacs.Background: light green" part, I include that because I always forget which Emacs is which.
Gotchas: this Emacs has its own package directory in its own .emacs.d directory. That may or may not be what you want. If you want to share the package directory, you can change package-user-dir or create a symbolic link to the to-be-shared package directory using Link Shell Extension.
Somethings to consider for running Emacs on a USB drive:
Emacs outsources some of its features to external tools. Grepping and comparison are outsourced to grep and diff, so you probably have installed at least GnuWin32 Grep and GnuWin32 DiffUtils on your system. And part of spell checking is outsourced to aspell, which is also a separate install. Encryption is outsourced to GPG, so Gpg4Win another separate install. For your portable Emacs to have all those features, all those external tools should be on your USB drive as well. Fortunately, GnuWin32 and aspell are portable-friendly. I don't know if GPG is. The dependency to external grep may be eliminated if you manage to make versions of lgrep and rgrep that only depend on eshell's own grep, but it seems nobody has done it, so making such lgrep/rgrep is to boldly go where no man has gone before.
You can get help on all of the emacs options by typing emacs --help on the command line. That help shows that --user expect the name of a user, not the path to an elisp file.
To load a lisp file at startup you can use the --load option:
$ emacs --help
...
--load, -l FILE load Emacs Lisp FILE using the load function
...
If you want to prevent your default init file from loading, you can use this option:
$ emacs --help
...
--no-init-file, -q load neither ~/.emacs nor default.el
...
I have a MacVim setup on my OSX machine so that the default Vim application (ie: /usr/bin/vim) is actually a symbolic link to the command-line version of Vim that ships with MacVim (ie: /Applications/MacVim.app/MacOS/vim), as it provides some key benefits over the stock Vim that ships with OSX10.6.
I periodically need to prepare a diff between a set of files, and export it into a colorful side-by-side-view HTML file. This is commonly achieved via:
vim -d file1 file2
(Within Vim): toHTML
The problem with this is that I have to manually check out the HEAD revision and a specific revision of the two sets of files, and do this operation for each pair of files. This is very time consuming.
Is it possible to have the results of svn diff command piped into Vim so I can have a colorful side-by-side-view diff for an entire directory (ie: the PWD), as opposed to just the unified diff view?
I have found several Vim scripts and bash scripts that attempt to achieve this, but there are two key problems:
I wish to explicitly call vim -d as the diff tool, and not vimdiff, as the MacVim application does not appear to ship with vimdiff, so I would be using the wrong version of Vim when launching the application
I wish to have multi-file diffs generated against an entire directory recursively, as opposed to just one or two files at a time.
If this is not feasible, I could likely create a bash script that more-or-less achieves this, but I'd like to avoid putting together a hacked/unreliable script if there is a more effective means of doing this.
Thank you.
vimdiff is merely an alternate name for vim. The binary checks to see how it's launched and determines its behavior accordingly. (That's why there isn't a different file for gvim and vim also.)
On my Mac OS and Linux machines I created a ~/bin directory, and then inside it created soft-links from the various names to my macvim binary. I put ~/bin very early in my path.
I'm not at work where I could check to make sure, but I think you can change the default SVN diff to point to vimdiff in ~/.subversion/config. Look for the diff-cmd section. https://stackoverflow.com/a/9604604/128421 might give you some useful information too.
You can try my aurum plugin, it ships with :AuVimDiff command which is as well capable of viewing all changes in a multiple tabs with vimdiff split:
AuVimDiff full HEAD 300
and get diffs between two revisions without you having to checkout them manually:
AuVimDiff file file1 HEAD 300
(file file1 part is optional, it will open diffsplit with current file if omitted. All revisions are also optional, for subversion specifying one revision is diffing it with file in the working directory and specifying no revisions is like svn diff: between BASE and working directory.)
300 here is just an example revision.
I have since resolved this fully in another, more recent post of mine. Posting a backtrack URL to it for future readers:
VIM - Passing colon-commands list via command-line
oh my god...i faced a big problem...i was created a .bash_profile in ~ folder and then set paths there...bust the big problem is after restarting my bash i see that none of my commands work like LS and RM and etc...
now i dont know how to fix it...some one help me...i need my terminal as soon as possible...
Make sure you are appending to the existing $PATH.
PATH=$PATH:/Users/mthalman/bin
To prevent this happening in the future:
When I edit my environment files (including bashrc, profile, login, and others), I always try starting another shell before quitting my editing environment. This protects me from the possibility of breaking my environment so that I can't log in.
Make sure your PATH includes the usual bin directories: /bin and /usr/bin.
First I would rename ~/.bash_profile to ~/old.bash_profile.
Then open that up in TextEdit (as a plain text document) and verify how you have set your path.
If you would prefer to use vim/emacs/nano/whatever, the act of renaming the file will allow new terminal sessions to use default paths, so from the command line you should be mostly fine.
Then verify you haven't clobbered $PATH as suggested by #Mark Thalman, above.
If you are in a Terminal Window, simply add in the /bin and /usr/bin back in your PATH.
$ PATH="/bin:/usr/bin:$PATH"
That should allow all the basic Unix command to work once more. Or, you can use the full path name for commands:
$ PATH="" #Can't find nothin'
$ ls
bash: ls: command not found.
$ /bin/ls -a #This will work!
. .. .bash_profile foo bar
Don't Reset PATH in your .profile!
As you discovered, you should never reset PATH in your `.bash_profile. Instead, you should always append and prepend to it:
PATH="/usr/local/bin:$PATH"
PATH="$PATH:$HOME/bin"
The first line will prepend /usr/local/bin to PATH which means if a command is in /usr/local/bin and /usr/bin, the /usr/local/bin version will be executed. Many system admins will put alternative base system commands in /usr/local/bin. For example, on Solaris, they might put VIM in /usr/local/bin/vi, so when you edit a file, you're using the improved VIM and not the base VI.
The second line appends your $HOME/bin to the end of $PATH. That means if there's a /bin/ls and you have ~/bin/ls, the /bin/ls will be executed first.
Never set PATH from scratch because each Unix system might have commands that you to access elsewhere in the system. For example, your site might require you to use X11, so you want /usr/X11/bin in your PATH, or you have GIT installed under the /opt/git directory, and you'll need /opt/git/bin in your path.
Sometimes, base utilities like ls might be replaced with upgraded versions of these utilities. On Solaris, you have the base vi and ls command, Most users like the GNU ls command because it uses color and prefer VIM to plain VI. I would included these utilities in /usr/local/bin and prepend that to my PATH.
And now a Word from a Sponsor
As you probably discovered, Finder doesn't list hidden files. That's why you can't see .bash_profile in Finder. You can use some hacks to change this, but it requires you to type them into the terminal window.
I use a Finder replacement called Path Finder. It contains a lot of neat Power User things such as allowing you to see hidden files, treat Packages such as apps as directories, and be able to view protected directories if you have Administrator access. There's a built in terminal and GUI Subversion client.
It's not cheap ($40), but you can download for free and try it out for 30 days.
BTW, I have absolutely no relationship to Cocoatech except as a customer, and I make no money from people buying Path Finder. It's just a tool I use.
Heading says it all really. Using Windows 7 and latest stable gvim, whenever I save (:w) a file it's marked executable. I'm doing cross-platform development and it'd be nice if this didn't happen.
#sceptics: The flag of the files are indeed set as executable. Do a ls -al before and after re-saving the file to observe the issue. (install cygwin, or may be other *nix emulations)
#OP: the question have been raised several times in the past. I don't remember the conclusion on the subject. You should search vim mailing-lists archives (vim_use and vim_dev).
May be you can try to add an hook to your RCS (if it supports that) to proceed to a chmod -x on file extensions that does not correspond to an executable (*.h, *.cpp, *.vim, ...), or on files that do not contain a shebang (unlike perl, I don't know if python source files may contain a shebang)