i was reading this thread ubuntu/linux bash: traverse directory and subdirectories to work with files and i thought maybe it can be twisted a little bit
Can this be set to:
be given a base folder
scan folder + subfolder
collect all files it finds (only images)
pick one randomly
write a symbolic link to /user/share/backgrounds directory (writing the image itself overwriting existing one may work as well)
what i intend is to execute the script upon system shutdown or at set interval so it will change the gdm background image..
this is based on a step to do it manually with this line
sudo ln -s /usr/share/applications/gnome-appearance-properties.desktop /usr/share/gdm/autostart/LoginWindow/
which prompts for the appearance dialog on startup, which writes the link.
Ideally, it would have a GUI to do it at will, and an option to "change it automagically upon restart" which will do the process i described above and add itself to system start, reboot or shutdown sequence.
Since theres no working utility atm for this, it might come handy for some people =)
thanks for your help.
Use Wallpapoz. It can change wallpapers randomly across workspaces and over time.
Related
Tractor is an operation that adds power to GWAS for an admixed individual. There are online tutorials, but I am struggling to even start running Tractor in MobaXTerm. Every time I try to run some of the code I get back "cant open file - whatever file - no such file or directory". I do not know how to implement the correct files needed to run the operation and have tried downloading files and opening in the MobaXTerm app. Do I need to create a whole separate directory? I am pretty new to using Moba and don't really know where to start with Tractor.
We have an utility to process images, built as a standard Applescript droplet (using the code floating around with distinction between folders and individual files).
On one installation (MacBook Pro, macOS 11.5), dragging on a single folder works fine, but when dragging on a selection of 4 files, only 2 get processed. An alert at the beginning of the code confirms that only two files are "taken". Various tests by exclusion show that we have a set of 2 specific files which make the other 2 not being processed. If in the group we drag onto the droplet, one of those files is included, only that one gets taken.
On other installations (iMac, macOS 11.5 or virtual macOS 10.14), this effect does not show up with the same files.
Has anyone heard of such an effect? What can be the cause? What can be done to avoid it?
Any hint is highly appreciated.
Thanks a lot in advance.
As mentioned in a comment, it seems to be a timing issue when feeding the files into the droplet, caused by the Quarantaine flag.
This keword lead to https://superuser.com/questions/1336044/how-to-clear-remove-macos-extended-attributes-recursively-from-a-directory on how to display and remove that flag. After removing it, all files processed properly.
What I will have to do now, is build a little utility which allows to strip that flag, as the issue happens when feeding the droplet.
I'm using project.vim with VIm to manage large code bases with deep directory structures.
When I switch to another one or create (\C) a new one and do a refresh (\R) project.vim starts displaying messages through the whole process for different directories:
<dir_name> is not a valid directory. [O]K:
I have to press Enter all the time, although the directories exist. I took a look at the code and it checks if the path is a directory. They are.
Maybe there is a fix for this. The directories are under Perforce management, so everything is read-only.
I have to stay at the keyboard and keep pressing Enter for it to go to next directories... For large code bases this is takes a long time.
I contacted the author some time ago, but there was no response.
Did anyone encounter this before?
Could it be the it is bothered by the read-only-ness?
Is there a fix for this?
Thanks
The plugin uses glob() for some of those directory checks, which is affected by the 'wildignore' setting. Try
:set wildignore=
If that fixes the problem (and you have at least Vim version 7.2.51), you can modify the plugin's code to use glob(..., 1) instead.
I have a problem when I detect accessing folder on Mac in python programming.
I use Pyinotify, watchdog, fsevent to monitor files change, it's very good, but now I need to detect when I access into a folder. I want to know when someone opens up the Finder at a folder so I can check for changes to that folder only
Ex: I'm currently in here folder/
and when I go to folder/folder_children , my python program can know that.
Anyone know how to detect it?
You may want to use Watchman. We provide a (not currently very well documented) python client and it works on Linux and Mac (and Solaris and FreeBSD)
https://facebook.github.io/watchman/
For your use case, the following aspects of Watchman are pertinent:
Watchman builds a time ordered index of file changes
Each logical change has an associated "clock" value
You can query Watchman for the list of files that changed since a clock value
For convenience you can ask Watchman to track a clock value with a symbolic name; we call these named cursors
For example:
When I run watchman since /path/to/dir n:myclient the first time, I get a complete list of files in /path/to/dir. When I run it the second and subsequent times it returns the list of files that changed since the last time it was run.
You can construct more sophisticated queries than since to match certain files; pertinent docs:
https://facebook.github.io/watchman/docs/cmd/since.html
https://facebook.github.io/watchman/docs/cmd/query.html
Architecturally:
On the remote side, run the Watchman service and ask it to monitor the root of the filesystem tree that you're syncing. Watchman always watches recursively.
On the client side, you can periodically (or via whatever heuristic you use to figure out when is appropriate) call up to the server
When polled by the client, the server issues a since query to Watchman using a cursor name
Your server only needs to re-examine the files in that list
You can use a separate cursor name per discrete client if you have multiple clients to synchronize.
I recently moved my whole local web development area over to using MacPorts stuff, rather than using MAMP on my Mac. I've been getting into Python/Django and didn't really need MAMP any more.
Thing is, I have uninstalled MAMP from the Applications folder, with the preferences file too, but how come when I run the 'locate MAMP' command in the Terminal it still shows all my /Applications/MAMP/ stuff as if it's all still there? And when I 'cd' into /Applications/MAMP/ it doesn't exist?
Something to do with locate being a kind of index searching system, hence things these old filepaths are cached? Please explain why, and how to sort it so they don't show anymore.
You've got the right idea: locate uses a database called 'locatedb'. It's normally updated by system cron jobs (not sure which on OS X); you can force an update with the updatedb command. See http://linux-sxs.org/utilities/updatedb.html among others.
Also, if you don't find files which you expect to, note this important caveat from the BUGS section of OSX' locate(1) man-page:
The locate database is typically built by user ''nobody'' and the
locate.updatedb(8) utility skips directories which are not readable
for user ''nobody'', group ''nobody'', or world. For example, if your
HOME directory is not world-readable, none of your files are in the database.
The other answers are correct about needing to update the locate database. I've got this alias to update my locate DB:
alias update_locate='sudo /usr/libexec/locate.updatedb'
I actually don't use locate all that much anymore now that I've found mdfind. It uses the spotlight file index which OSX is much better at keeping up to date compared to the locatedb. It also has quite a bit more power in what it can search from the command line.
Indeed the locate command searches through an index, that's why it's pretty fast.
The index is generated by the updatedb command, which is usually run as a nightly
or weekly job.
So to update it manually, just run updatedb.
According to the man page, its database is updated once a week:
NAME
locate.updatedb -- update locate database
SYNOPSIS
/usr/libexec/locate.updatedb
DESCRIPTION
The locate.updatedb utility updates the database used by locate(1). It is typically run once a week by
the /etc/periodic/weekly/310.locate script.
Take a look at the locate man page
http://unixhelp.ed.ac.uk/CGI/man-cgi?locate+1
You'll see that locate searches a database, not your actual filesystem.
You can update that database by using the updatedb command.
Also, since it's a database, unless you do update it regularly, locate wouln't find files that are in your filesystem that arn't in the database.