when I update my gcc in my macbook
it occurs:
org.macports.extract for port llvm-3.5 returned: Failed to locate 'xz' in path: '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin' or at its MacPorts configuration time location, did you move it?
but actually I don't move anything because I am a newbie,when it downloads from macport ,for too slow network speed I press some return button and it seems to have this situation that download for llvm-3.5 is failed,but it seems that I can't redownload it.
what can I do to solve this and get my gcc updating?Thanks for telling me how to do it.
Either the file "xz" exists on your Mac or it doesn't.
To see if it exists, type this into the command line:
( find / -name xz -print > /dev/tty ) > & /dev/null
And what that does is that it scans your entire hard disk for a file named exactly "xz", piping any errors (i.e. files that can be read because of permission issues) away and leaving you with the path to "xz".
If "xz" exists, you can add the path to your .tcshrc file, or if it doesn't exist, you need to get it.
Related
I had MAFFT running fine on my computer (MacOS 11.6), until I downloaded PRANK (a probabilistic multiple alignment program distributed by Wasabi) which also runs on its own MAFFT Unix executable file. The original MAFFT is located in the directory /usr/local/bin, and PRANK and its associated files live in another directory called /programs/prank/bin, both of which are in my $PATH variable, with the /usr/local/bin directory having priority. Now, not only is the MAFFT within PRANK giving the error below when I type the ‘prank’ command, but I also get this error when trying to use my original version of MAFFT by typing ‘mafft.’ Deleting my original MAFFT and only using the PRANK version does not fix things. If I fully delete PRANK and MAFFT and redownload MAFFT alone, I can get it to work again.
I’ve tried all the steps listed in the error output below. My $MAFFT_BINARIES file appears to be empty or nonexistent, and there is no MAFFT_BINARIES line in my .bash_profile or any of the other settings files listed.
Does anyone have any insight into what may be causing this or how I should go about fixing it? Has anyone experienced the same conflicts with PRANK? Please let me know if I can provide any additional information about my system or set-up that would be helpful. As you might be able to guess, I'm not particularly experienced in this level of digging around in the guts of my file directories, but I know just enough to get myself into trouble...
Error: Initial alignment with Mafft failed. The output generated was:
v7.490 != v7.450 (2019/Aug/23)
There is a problem in the configuration of your shell.
Check the MAFFT_BINARIES environmental variable by
$ echo $MAFFT_BINARIES
This variable must be *unset*, unless you have installed MAFFT
with a special configuration. To unset this variable, type
$ unset MAFFT_BINARIES
or
% unsetenv MAFFT_BINARIES
Then retry
$ mafft input > output
To keep this change permanently, edit setting files
(.bash_profile, .profile, .cshrc, etc) in your home directory
to delete the MAFFT_BINARIES line.
On MacOSX, also edit or remove the .MacOSX/environment.plist file
and then re-login (MacOSX 10.6) or reboot (MacOSX 10.7).
Please send a problem report to katoh#ifrec.osaka-u.ac.jp,
if this problem remains.
I recently had a git conflict, and rather than dealing with it properly, I didn't actually fix any of the conflicts, but did something like overwrite the files with another version from another clone of the repo, or moved the files out of the directory, or did a git reset --soft, or some other convoluted series of commands.
Anyway, I've been left with some files on my filesystem that I cannot delete. I cannot move them, rename them, delete them with DEL in the command line, or with RM in gitbash. The file is named:
pom.xml~9b19d48... dpom_refactor
It has 0 bytes, and I've no clue how to get rid of it. I no longer have any .git folder, so I can't use any git commands to rollback what I did. Whenever I attempt to delete/move/rename, I get the error:
Could not find this item
This is no longer located in C:\<filePath>. Verify the item's location and try again.
Any thoughts on how I could get rid of it?
This kind of invalid Windows filename could be dealt with like a nul file.
C:\> rename \\.\C:\..\pom.xml~9b19d48... dpom_refactor del.txt
C:\> del del.txt
Using the \\.\ prefix tells the high-level file I/O functions to pass the filename unparsed to the device driver
If that was to fail, only a dedicated tool (or Live Linux distro CD) would be able to mount that disk and remove the file.
I have just installed NS2 on Mac OS X Mavericks (10.9)
I have set all the paths correctly.
I can successfully type 'ns' on the terminal, and 'nam' as well, and both execute without any problem.
The problem is that when I input a file to the ns command, it says:
couldn't read file "example.tcl": no such file or directory
I use this command in the terminal:
ns example.tcl
I also tried it running it in sudo mode:
sudo -s
ns example.tcl
I placed the file in the bin folder, where there's ns's shortcut, I also placed it where actually the ns is. I also tried giving it a full path to the tcl file, but no use in both the cases.
I also tried to run it after executing only ns first, and then within ns ran it (No idea if it works like this, I am just trying everything I have got!)
ns
%ns example.tcl (Hash sign shows the NS is running and I am typing the command there)
This time the error is:
warning: using backward compatibility mode
error when calling class OldSim: hello-ddos.tcl
The version of NS is 2.35.
NOTE: I changed the file extension from .tcl to .txt, and it works fine now. Any idea of the problem?
Please help!
The error message:
couldn't read file "example.tcl": no such file or directory
is pretty clear. It simply couldn't find the file; the OS returned an ENOENT error from the underlying system call to open the file. The usual reason for this is that the file isn't in the directory that you're running the program from, and the usual recommendation for dealing with this is to use the full name of the file instead of just the local path-less version. (It's technically possible for there to be other issues, but they usually produce different errors.)
What can cause this? Well, one of the most common things is if you (or some library code, such as what is inside NS2) does a cd to change the current directory. Using a full, absolute filename makes (or at least should make) your code much more resistant to that sort of thing.
Warning: note that the second part of your question relating to changing the filename is strange to me.
Check the directory of your file. It should be in the bin folder inside your ns folder.
Also you may try typing
sudo ./ns filename.tcl
to give you root access if by any chance you are detached from that.
Before installing Lion, when I tried to ignore something on my svn, I just typed the following command:
svn propedit svn:ignore .
This opened a temporary file for the current directory with the selected editor and I could write there my patterns, which where ignored by svn.
After I installed Lion, when I type this command the following error appears: The document “svn-prop.tmp” could not be opened. The file doesn’t exist.
Did anybody else met this error before? (I tried googling, but I didn't find any solution).
SVN_EDITOR=/Applications/TextEdit.app/Contents/MacOS/TextEdit
It seems that with Lion it is no more possible to open a file with TextEdit on the command line giving the file name as argument.
A workaround is to use open
export SVN_EDITOR='open -e -W -n '
-e tells to open with TextEdit (use -a if you want to specify a different application)
-W tells open to wait for TextEdit to quit. If not specified svn propedit will read the file before it's edited and return telling the no changes were done.
-n tells to open a new instance of TextEdit even if there is another one already open. On one hand it will avoid that you have to quit an open editor and on the other hand it was not working without the option :-)
I am creating a bash script to backup my files with rsync.
Backups all come from a single directory.
I only want new or modified files to be backed up.
Currently, I am telling rsync to backup the dir, and to check the files compared to the last backup.
The way I am doing this is
THE_TIME=`date "+%Y-%m-%dT%H:%M:%S"`
rsync -aP --link-dest=/Backup/Current /usr/home/user/backup /Backup/Backup-$THE_TIME
rm -f /Backup/Current
ln -s /Backup/Backup-$THE_TIME /Backup/Current
I am pretty sure I have the syntax correct for this. Each backup will check against the "Current" folder, and upload only as necesary. It will then delete the Current folder, and re-create the symlink to the newest backup it just did.
I am getting an error when I run the script:
rsync: link "/Backup/Backup-2010-08-04-12:21:15/dgs1200series_manual_310.pdf"
=> /Backup/Current/dgs1200series_manual_310.pdf
failed: Operation not supported (45)
The host OS is running HFS filesystem, which supports hard linking. I am trying to figure out if something else is not supporting this, or if I have a problem in my code.
Thanks for any help
Edit:
I am able to create a hard link on my local machine.
I am also able to create a hard link on the remote server (when logged in locally)
I am NOT able to create a hard link on the remote server when mounted via afp. Even if both files exist on the server.
I am guessing this is a limitation of afp.
Just in case your command line is only an example: Be sure to always specify the link-dest directory with an absolute pathname! That’s something which took me quite some time to figure out …
Two things from the man page stand out that are worth checking:
If file's aren't linking, double-check their attributes. Also
check if some attributes are getting forced outside of rsync's
control, such a mount option that squishes root to a single
user, or mounts a removable drive with generic ownership (such
as OS X's “Ignore ownership on this volume” option).
and
Note that rsync versions prior to 2.6.1 had a bug that could
prevent --link-dest from working properly for a non-super-user
when -o was specified (or implied by -a). You can work-around
this bug by avoiding the -o option when sending to an old rsync.
Do you have the "ignore ownership" option turned on? What version of rsync do you have?
Also, have you tried manually creating a similar hardlink using ln at the command line?
I don't know if this is the same issue, but I know that rsync can't sync a file when the destination is a FAT32 partition and the filename has a ":" (colon) in it. [The source filesystem is ext3, and the destination is FAT32]
Try reconfiguring the date command so that it doesn't use a colon and see if that makes a difference.
e.g.
THE_TIME=`date "+%Y-%m-%dT%H_%_%S"`