Compared with KDE 3 there seems to be some missing. Sort of hoping some one is using it - does it work now?
The missing parts seem to be launching a KDE application from a shell script and if control returns to the script after the application is closed. Anyone have any information on this sort of thing?
There is also this one which can control the desktop but I assume KDE apps can be launched from a shell script so it may be a little over the top. Docs are also rather scant.
Additionally java script can be used to script a number of things but it doesn’t seem to offer access to the shell. There also seems to be variations on what type of scripts can control Kwin. Qt scripts are mentioned in places. I assume that’s QML.
If you want to control an application from a script this can also be done over DBUS (the successor of DCOP).
Have a look at qdbusviewer to find out what running application supports which interfaces.
You can call methods and so on from shell scripts with “qdbus” or “dbus-send”.
But IMHO you should explain what exactly you are trying to achieve, then people would be able to help better.
Thanks - I never imagined that --help would work. It also works on things like dolphin, konqueror, opera and even vlc and gives the calling options.
Going on their behaviour in the console running from a shell script just involves say “dolphin /” or “dolphin/home etc”. The only odd thing is when the select option is used there are still error messages - in my case as I don’t have a samba.conf it complains. More complaints from Dolphin than Konq. I suppose the output can be sent to null. Control is passed back to the console after what ever is launched is closed - even a tab in opera. lol!I’m impressed as have had the impression that KDE was moving away from this sort of thing.
The script is interesting to as it details creating a desktop icon. I have wondered about that and last time I looked couldn’t find any documentation on their content or construction at all. Is there any around now?
Use - as a for instance. On 11.4 for various reasons I tried to do this
Obtain a password - mount a nas using cifs directly - open a dolphin window directed to a place on the nas - log off the nas when dolphin was close and not allow the icon to be used again until logged off the nas.
No luck via KDE so I finished up trying to do this with Qt and then found that the docs didn’t tie up and were not up to date. Really it isn’t even worth considering js or c etc for something like this. Going on a video I watched QML would probably be my choice for anything that needed more facilities. Might interest some. There are also a number of other video’s
Use “dolphin /home 2>/dev/null” to suppress the debug output (that mostly comes from udisks2).
The script is interesting to as it details creating a desktop icon. I have wondered about that and last time I looked couldn’t find any documentation on their content or construction at all. Is there any around now?
I haven’t had a look at that script. Do you mean how to create a .desktop file?
Here are the specifications: Desktop Entry Specification
Obtain a password - mount a nas using cifs directly - open a dolphin window directed to a place on the nas - log off the nas when dolphin was close and not allow the icon to be used again until logged off the nas.
Something like:
#!/bin/bash
PASSWORD=`kdialog --password "Enter password"`
if $? -eq 1 ]; then
# user clicked cancel
exit 1
fi
mount //HOST/SHARE mountpoint -o username=xxx,password=$PASSWORD
dolphin mountpoint 2>/dev/null
umount mountpoint
Of course you would have to adapt at least the mount call (see “man mount.cifs”), and you would have to run this as root to be able to mount (if you use sudo you would have to enter the root password as well).
And you could check at the beginning of the script if the nas is still mounted (grep the output of mount f.e.) and exit in that case.
And why don’t you just use “dolphin smb://HOST/SHARE” or “dolphin smb://user@HOST/SHARE”? Of course it’s not mounted then.
Or maybe use some FUSE-based filesystem.
I recompiled mount.cifs so that it was user mountable once again - more like nfs.
Going on some one else’s recent experiences there may be no need to do that any more under 12.3.
At the time the nas could be handled entirely from KDE but boot and navigation were slow. The other problem was rather strange. Take Kwrite and it could read/modify/write files on the nas. Many other apps couldn’t. The other problem was launching files from the nas eg a Photo. Problems again and I often work like that.
cifs was down to the nas and there being windoze users here - adding nfs is more work for the nas to do. Discouraged in it’s doc’s.
That’s not possible. Having to be root to mount is not a restriction of mount.cifs but the kernel.
You could add an entry for your NAS in /etc/fstab with the option “user” of course. Then you can mount it as user.
But I don’t know if you can specify the password= option then using mount. If not, you could try to set PASSWD instead of PASSWORD since mount.cifsrespects that variable. (Again, see “man mount.cifs”)
Or you could use a FUSE-based filesystem to mount your NAS. See: SourceForge.net: NetworkFileSystems - fuse (I don’t want to check now which of them are available as packages for openSUSE)
At the time the nas could be handled entirely from KDE but boot and navigation were slow. The other problem was rather strange. Take Kwrite and it could read/modify/write files on the nas. Many other apps couldn’t. The other problem was launching files from the nas eg a Photo. Problems again and I often work like that.
Right. KDE has the so-called “KIO” system via which KDE applications can access f.e. files on network servers like if they were on the local hard disk. See KIO - Wikipedia
GNOME has something similar.
But only some non-KDE and none-GNOME programs support something similar as the “smb://” kioslave. (I only can think of media players like xine, mplayer and VLC, or Webbrowsers like Opera and Firefox right now; though there may be other programs of course…)
That of course makes it necessary to mount the share.
What I’d also like to mention:
For this particular use case (mounting and unmounting your NAS) you could also have a look at Smb4K: Smb4K | Free Development software downloads at SourceForge.net
This program lets you browse the SAMBA/CIFS shares in your network and mount/unmount them (and can automatically call dolphin when mounting).
It is part of the standard openSUSE repo, so you can easily install it using YaST.
And regarding the Desktop icon, you can also let KDE create the .desktop file for you.
Just right-click somewhere in the folderview or dolphin and select “Create New”->“Link to Application…”.
I don’t mind entering the password when I use the nas. In fact I have come to prefer it that way. I hit the up arrow in the console until the last time I mounted it comes up, hit return and then enter the pass word when requested.
I’m on my new machine so have no idea what if anything I put into fstab. If there is anything it’s a left over from when I did it server style for want of a better word. Problem then as well as the ones I mentioned was slow navigation as the techniques assume more than one user on the partition. In this case it’s private so there is no need to check for changes when navigating up and down directory trees. Actually I have seen indications that using a shared partition as a drop box to exchange files with others is ok too.
I need to go back on the old machine one more time. Be interesting to see what is in fstab. I posted the changes to mount.cifs recently.
KIO to me is a bad idea. The i/o of this sort is built into the kernel and in my view best left there. The problem is that they can obtain code from other projects and use and change it. Easy to do but may not be generally compatible. I had the impression that desktop files had something to do with compatibility but probably a red herring. Qtified applications may well be ok now. One problem though. The KDE boot up time taken to connect to the nas was far longer than I am prepared to put up with. Direct mounting is instantaneous.
rotfl! Thanks for the other link but I will probably do it my way just to see if I can.
That won’t work.
The option “user” doesn’t take an argument. If specified, you are allowed to mount the entry as normal user.
To specify the username for your NAS, you would use “username=john”.
If you want to have the user own all files on the mounted filesystem, you can do that with “uid=john”. (and maybe “forceuid”)
And to specify the group id, you would have to use “gid=Nas1”. (and maybe “forcegid”)
See “man mount” and “man mount.cifs” (as already mentioned).
I will make a note of that but I can assure that along with the mount instruction it does work on 11.4. I’ve been regularly using it for a long time now. Not now though as I haven’t set up anything on my new machine and wont be for a while yet.
Checking further the man fstab refers to mount(8) which in turn refers to fstab(5) which I don’t seem to have and the real options must be in mount.cifs. I assume it’s accepted user that way instead of as an environment variable. Pass on guid but maybe things have changed since 11.4. Oddly the url is incorrect as well yet as I pointed out I have been using it like this for a long time.
It took several hectic days to set up as any time I asked about cifs people started mentioning samba. Not what I wanted.
This time I will start at the mount.cifs end and then add what seems to be needed. Before I was hampered by not knowing that I needed to edit and re compile mount.cifs. Not sure if I need to do that on 12.3. Have to look at the source.
“man mount.cifs” explains the specific mount options for cifs, while “man mount” explains the general options (and those for other filesystems).
And “mount fstab” explains the structure of the /etc/fstab file.
Maybe you ran “man fstab(5)”? That’s wrong syntax.
It should be “man 5 fstab”. But since there’s only one fstab manpage, this is equivalent to “man fstab”.
I assume it’s accepted user that way instead of as an environment variable. Pass on guid but maybe things have changed since 11.4. Oddly the url is incorrect as well yet as I pointed out I have been using it like this for a long time.
I don’t know about guid, but “user” was always for allowing users to mount.
This time I will start at the mount.cifs end and then add what seems to be needed. Before I was hampered by not knowing that I needed to edit and re compile mount.cifs. Not sure if I need to do that on 12.3. Have to look at the source.
Why would you have to change and recompile mount.cifs? I don’t understand. What changes would that be?
I’ve been away from home and off the internet for a while.
I think I read that the any user option is now users. As to a USER file etc that still seems to be there.
The source modifications and recompile were down to changes made between 10?.? and 11.4. When I bug reported the problems it caused with typical home nas’s I was told that the changes had been made because certain people kept asking if mount.cifs was secure and no one was prepared to do a security audit on it. The comments mainly seemed to be samba orientated.
I don’t play at this level often so can’t use the correct terminology but I understand one change prevented root writing a script to allow a user to mount a cifs directory. The other change prevented me from mounting as I wanted to - this may be incorrect though as I had a hard time - started with a shell script expected it to work and it wouldn’t. Many hours web searching which is probably where the fstab entries came from.
I posted the changes to the mount.cifs source part way down this thread. They also added a mount.cifs.install - pass on what that does.
From some one else’s comments 12.3 can be used in the usual way. The 1st time I had problems I extracted mount.cifs from an earlier release. Couldn’t do that on 11.4 so I changed the source.
“user” and “users” is not exactly the same. Both options exist.
From “man mount”:
**The non-superuser mounts.
** Normally, only the superuser can mount filesystems. However,
when fstab contains the **user** option on a line, anybody can mount
the corresponding system.
Thus, given a line
** /dev/cdrom /cd iso9660 ro,user,noauto,unhide**
any user can mount the iso9660 filesystem found on his CDROM
using the command
** mount /dev/cdrom**
or
** mount /cd**
For more details, see **fstab**(5). Only the user that mounted a
filesystem can unmount it again. If any user should be able to
unmount, then use **users** instead of **user** in the fstab line. The
**owner** option is similar to the **user** option, with the restriction
that the user must be the owner of the special file. This may be
useful e.g. for /dev/fd if a login script makes the console user
owner of this device. The **group** option is similar, with the
restriction that the user must be member of the group of the
special file.
Regarding the “USER” file (that’s no file but an environment variable), see “man mount.cifs”:
**OPTIONS**
username=arg
specifies the username to connect as. If this is not given, then
the environment variable USER is used.
And I still don’t understand why you would recompile mount.cifs with that suid check disabled and make it suid root when you can just specify the “user” or “users” option in fstab.
But well, it’s your system, not mine…