Re: basic issue/question -- renaming in mass a bunch of files
On Sun, 25 Feb 2018 04:21:24 +0100 Wolfgang Pfeiffer wrote: > Only a tldr: > Both Debian and Fedora have the simple rename utility that is usable > without perl knowledge. > Only Fedora actually seems to have the extended version of Larry Walls "Only Fedora": No idea whether the extended version is on other OS's available - I simply didn't find it on Debian ... > rename, namely prename, which was done by Peder Stray. While prename > utilities on Debian, that I found *so far*, seem to be renamed (sic! ... :) > versions of Larry Wall's rename. > > HTH -- Wolfgang Pfeiffer ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, 24 Feb 2018 19:48:23 -0500
Todd Zullinger wrote:
> Patrick O'Callaghan wrote:
> > I wonder if that version is actually prename ('dnf install prename')
> > under a different name, which would be nicely ironic ...
>
> Heh. I think they're different. I'm not a Debian user
> though, so I could be way off on what follows. :)
>
> This gets quite messy. The /usr/bin/rename command is
> managed by alternatives in Debian. The default for rename
> in a docker container of Debian 8 is file-rename.
Only a tldr:
Both Debian and Fedora have the simple rename utility that is usable
without perl knowledge.
Only Fedora actually seems to have the extended version of Larry Walls
rename, namely prename, which was done by Peder Stray. While prename
utilities on Debian, that I found *so far*, seem to be renamed (sic! ... :)
versions of Larry Wall's rename.
HTH
--
Wolfgang Pfeiffer
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: samba share without authentication
On 02/24/2018 05:37 PM, Tom Horsley wrote: But can a windows 10 box automatically mount it with no user interaction like it once could do with public shares before they got rid of the public share mode? Yes. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On 25/2/18 1:03 am, bruce wrote: Hi. Have a bunch of files with the basic naming of: ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat etc.. I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the files, renaming the files to the rest of the filename.. Thought it should be simple using rename rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat However, this didn't work... so.. hmm.. How would you guys solve this? SO has a bunch of different solns as well. thanks... Just some info on this, rename 'ztcloud_nfs_parsezt' '' zt*.dat will remove the required first part from the file names. regards, Steve ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: Nvidia Module Tainting Kernel
On 02/25/18 09:57, Stephen Morris wrote: > On 24/2/18 11:12 pm, Ed Greshko wrote: >> On 02/24/18 12:43, Stephen Morris wrote: >>> Thanks Ed. Is there any documentation anywhere on what each bit represents? >> You mean other than the URL I've supplied at kernel.org and the comments >> within >> tainted.c ? > I haven't seen tainted.c as yet so I'm not sure what it has commented, but > the info > in the url indicates that bit 1 can have two reasons for being set, so my > query is > more around if a bit that has multiple reasons is set, how does one determine > which > of those reasons is causing it to be set. The number 1 is a list number in the kernel.org URL I've supplied. As I've repeatedly said, the "BIT" is the number in the list "MINUS" one. So, BIT 0 is concerned with the GPL License status. Yes there is an "OR" condition but the situation is still the SAME. There is a problem with the LICENSE of a module which is deemed a "TAINT". Not complicated. As for tainted.c, I sent you the URL for that file/program that you need to compile and run according to the directions in the file. I'm surprised that with your being so concerned about what taints your kernel you've not looked at the file, not compiled, and I guess not run the program? https://paste.fedoraproject.org/paste/a6HyoXLvYCMpjKeym-S~wg is tainted.c. -- A motto of mine is: When in doubt, try it out signature.asc Description: OpenPGP digital signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: Nvidia Module Tainting Kernel
On 02/25/18 09:46, Stephen Morris wrote: > [ 10.395281] razermouse: loading out-of-tree module taints kernel. > [ 10.395344] razermouse: module verification failed: signature and/or > required > key missing - tainting kernel > [ 10.874905] nvidia: module license 'NVIDIA' taints kernel. > [ 10.874907] Disabling lock debugging due to kernel taint > [ 123.187478] CPU: 6 PID: 825 Comm: systemd-logind Tainted: P OE > 4.15.4-300.fc27.x86_64 #1 > [ 123.194773] CPU: 3 PID: 655 Comm: nvidia-modeset Tainted: P W OE > 4.15.4-300.fc27.x86_64 #1 Look that the "P", "W", "O", and "E" in the messages above and reference them to those letters in the list in https://www.kernel.org/doc/html/v4.15/admin-guide/tainted-kernels.html Note the "time" in the message. These are just more information being supplied to you. They are informative. > > > Why are the two cpu messages now coming out for the first time, has the last > update > introduced something that is now causing these messages to be produced or has > there > been additional functionality added to the kernel to produce them. > > Looking at the nvidia one, this one is probably understandable given that the > nvidia drivers do taint the kernel, but I'm not sure where that module is > coming > from because when I use yumex to search for modeset I don't get any hits at > all. > > The systemd one is a bit disconcerting, from the perspective of any kernel > modules > that systemd has I would have expected to be a native part of the kernel, > hence > wouldn't be causing any tainted, hence what is this logind binary module that > is > being inserted into the kernel to cause tainting? The bottom line is, you're running a Wifi module and another module that you've complied yourself, your running the nVidia driver. Your kernel *is* tainted. You will/may get messages to that effect. Why they come at times and why they don't at others is immaterial. I've said it before, and I'll say it again. I'm not interested in chasing thatand I won't Unless you're system is failing. Unless your wifi is broken. Unless your graphics are freezing. Your system is running just fine. So, I'm pretty much at an end when it comes to this thread. There are *no* problems to be solved. So, your choice if you want to continue to worry about those messages and if/when they appear or don't appear. So, I'm done. -- A motto of mine is: When in doubt, try it out signature.asc Description: OpenPGP digital signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: Nvidia Module Tainting Kernel
On 25/2/18 12:15 am, Patrick O'Callaghan wrote: On Sat, 2018-02-24 at 15:43 +1100, Stephen Morris wrote: Are all these taint messages, and all the reasons for a taint message being produced saying that if we have to build our own drivers into the kernel to be able to use our hardware, and hence put us into the situation of potentially not getting support for kernel defects if any are encountered, that we shouldn't be using linux? If you encounter a kernel defect, how can it be debugged if part of the kernel is not available? That's what tainting amounts to. IIRC you've said that you compile the Nvidia modules. What you are actually doing is compiling code (the dkms system) that enables Nvidia's binary blobs to be linked as modules into the Linux kernel. You don't (unless you work for Nvidia) have the source code of those blobs. I can understand objects being linked together to build an executable module, but what I don't understand, based on what you are saying, is where the source code in the nvidia directory in /usr/src that dkms is compiling has come from if it hasn't come from nvidia? regards, Steve poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: Nvidia Module Tainting Kernel
On 24/2/18 11:12 pm, Ed Greshko wrote: On 02/24/18 12:43, Stephen Morris wrote: Thanks Ed. Is there any documentation anywhere on what each bit represents? You mean other than the URL I've supplied at kernel.org and the comments within tainted.c ? I haven't seen tainted.c as yet so I'm not sure what it has commented, but the info in the url indicates that bit 1 can have two reasons for being set, so my query is more around if a bit that has multiple reasons is set, how does one determine which of those reasons is causing it to be set. With bit 13 being set reflecting the loading of an unsigned module into a kernel supporting module signatures, is that because the kernel has been designed for secure boot, and will turning on secure boot resolve the signing issue? Probably not, since 13 and 12 are probably a pair in your case. Are all these taint messages, and all the reasons for a taint message being produced saying that if we have to build our own drivers into the kernel to be able to use our hardware, and hence put us into the situation of potentially not getting support for kernel defects if any are encountered, that we shouldn't be using linux? No. It is just saying that in the unlikely event you run into a kernel problem and you want to report it you should first check to see if others have the problem and/or try to reproduce it a non-tainted environment. Like running whatever you thought caused the problem in a QEMU/KVM environment. I don't think it is very likely that you're going to run into a kernel issue that needs reporting. I've never had a kernel crash except years ago when integrating the nVidia drivers was a DYI project. I have to admit I'm in the same situation as well, I haven't really had any kernel issues since the days when I was downloading the source directly from the nvidia site and also compiling my own kernel, because the binary kernel distributed with the distro was compiled for single cpu's only, hence running a quad core cpu meant that kernel was not useful, plus the source for their mp kernels had to be modified via the config because they were configured to support only 2 cores. regards, Steve ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: Nvidia Module Tainting Kernel
On 24/2/18 3:43 pm, Stephen Morris wrote: On 24/2/18 2:25 pm, Ed Greshko wrote: On 02/24/18 10:21, Stephen Morris wrote: On 23/2/18 8:59 am, Ed Greshko wrote: On 02/23/18 05:27, Stephen Morris wrote: From the responses I am getting it seems that the meaning of 'taints the kernel' has morphed into something else? Here is the definitive list of what taints the kernel. This is from the 4.14 documentation but is also valid for 4.15 kernels. https://www.kernel.org/doc/html/v4.14/admin-guide/tainted-kernels.html The numbers in the list correspond to the bit positions in the value supplied by "cat /proc/sys/kernel/tainted" Why you don't get "tainted" messages in your dmesg output or journal? Don't knowand I'd not be interested in chasing it down. I've a small program that converts the value from proc-tainted into real info if you need it. Access to that program would be great, the output from the cat command you mentioned above of 12289 is meaningless to me especially after looking at the web page you highlighted. 12289 = 110001 in binary [bit] [bit value] [description] 0 1 A module with a non-GPL license has been loaded. (bit 0 is rightmost bit) 12 4096 An out-of-tree module has been loaded 13 8192 An unsigned module has been loaded in a kernel supporting module signature 1 + 4096 + 8192 = 12289 The program I reference simply does the math for you. The source is tainted.c and located at https://paste.fedoraproject.org/paste/a6HyoXLvYCMpjKeym-S~wg Thanks Ed. Is there any documentation anywhere on what each bit represents? With bit 13 being set reflecting the loading of an unsigned module into a kernel supporting module signatures, is that because the kernel has been designed for secure boot, and will turning on secure boot resolve the signing issue? -- Snipping the Rest of the Message Just further to this, I did a system upgrade yesterday which installed a new kernel, so all the drivers were re-compiled. I have two versions of my wifi driver installed in dkms because the oldest of the 3 kernels that exist is using the older wifi driver (and with the kernel changes that were done that required a new version of the wifi driver to be obtained will potentially mean that the new version of the driver will not compile with the oldest version of the kernel I have), and with the kernel update that was done yesterday dkms for some reason decided to compile the wrong version of the wifi driver so I had to manually compile the driver with dkms to get wifi back again (the reasons why the wrong one was selected this time doesn't really matter, I have rectified the situation), but the last couple of compiles of the wifi driver I have done have highlighted that dkms has changed functionality. When I compiled the wifi driver, after the depmod process was run dkms ran dracut to update the associated initramfs, and produced messages about what the backup was called and to use the backup if the next boot failed. Now depending on how comprehensive the logic in this process is, it may or may not work, particularly when in my situation I am compiling 3 kernel modules that all potentially require initramfs changes (I know the nvidia driver does but I'm not sure about the mouse drivers). I know the main xorg nvidia package I am using installs a dracut config file but the wifi driver I am using does not because I am manually loading on the source into /usr/src, so I'm not sure why dkms run dracut when it is compiled, whereas it is understandable for the nvidia driver. In addition to the above, before I compiled the wifi driver, I ran a 'dmesg | grep -i taint', and that reported the out of tree taint messages for the mouse driver for the first time, plus it produced two new messages that prior to yesterdays update had never been produced before. The output from the command is below: [ 10.395281] razermouse: loading out-of-tree module taints kernel. [ 10.395344] razermouse: module verification failed: signature and/or required key missing - tainting kernel [ 10.874905] nvidia: module license 'NVIDIA' taints kernel. [ 10.874907] Disabling lock debugging due to kernel taint [ 123.187478] CPU: 6 PID: 825 Comm: systemd-logind Tainted: P OE 4.15.4-300.fc27.x86_64 #1 [ 123.194773] CPU: 3 PID: 655 Comm: nvidia-modeset Tainted: P W OE 4.15.4-300.fc27.x86_64 #1 Why are the two cpu messages now coming out for the first time, has the last update introduced something that is now causing these messages to be produced or has there been additional functionality added to the kernel to produce them. Looking at the nvidia one, this one is probably understandable given that the nvidia drivers do tai
Re: samba share without authentication
On Sat, 24 Feb 2018 17:27:54 -0800 Gordon Messmer wrote: > Logged in with no password. But can a windows 10 box automatically mount it with no user interaction like it once could do with public shares before they got rid of the public share mode? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: samba share without authentication
On 02/24/2018 11:57 AM, Tom Horsley wrote: (which they either made impossible or made so obscure it might as well be impossible). # cat /etc/samba/smb.conf [global] ... map to guest = Bad User [music] path = /home/samba/Music guest ok = Yes $ smbclient //storage/music/ -U '' Enter SAMBA\guest's password: Try "help" to get a list of possible commands. smb: \> ls . D 0 Sat Dec 10 21:27:32 2016 .. D 0 Mon Feb 19 11:19:10 2018 Logged in with no password. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
Patrick O'Callaghan wrote:
> I wonder if that version is actually prename ('dnf install prename')
> under a different name, which would be nicely ironic ...
Heh. I think they're different. I'm not a Debian user
though, so I could be way off on what follows. :)
This gets quite messy. The /usr/bin/rename command is
managed by alternatives in Debian. The default for rename
in a docker container of Debian 8 is file-rename.
The file-rename command comes from the rename package. It's
installed as file-rename rather than rename based on this
commit:
https://salsa.debian.org/perl-team/modules/packages/rename/commit/642262b4
The source of the Debian rename package is the perl
File::Rename module, here:
https://metacpan.org/release/File-Rename
The Fedora prename package points to:
http://search.cpan.org/dist/rename/
That's a different perl rename tool (since you can never
have too many rename tools, obviously). Debian ships
prename as well. It's in the rename alternatives group.
Debian also ships the util-linux rename as rename.ul, but it
doesn't seem to be in the alternatives group for rename.
Clearly, using the command in a script would be insane, as
you'd have more lines of code to determine which version you
were using than it would take to just rename the files using
whatever language the script was written in. :)
--
Todd
~~
A diplomat is a person who can tell you to go to Hell in such a way
that you actually look forward to the trip.
-- Anonymous
signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, 2018-02-24 at 23:40 +0100, Wolfgang Pfeiffer wrote:
> On Sat, 24 Feb 2018 13:14:49 -0500
> Tom H wrote:
>
> > On Sat, Feb 24, 2018 at 9:03 AM, bruce wrote:
> > >
> > > Have a bunch of files with the basic naming of:
> > > ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat
> > > ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat
> > > etc..
> > >
> > > I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the
> > > files, renaming the files to the rest of the filename..
> > >
> > > Thought it should be simple using rename
> > >
> > > rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat
> > >
> > > However, this didn't work... so.. hmm..
> >
> > Is "rename" provided by util-linux or is it a perl-provided script?
> >
> > The util-linux syntax is
> >
> > rename search_for replace_with
> >
> > while the perl-script syntax is
> >
> > rename 's/search_for/replace_with/'
>
> thanks for the latter sed syntax - good to know on Debian, IINM ...
I wonder if that version is actually prename ('dnf install prename')
under a different name, which would be nicely ironic ...
poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: More color problems -
On Sat, 2018-02-24 at 14:00 -0800, Joe Zeff wrote: > On 02/24/2018 01:55 PM, Patrick O'Callaghan wrote: > > On Sat, 2018-02-24 at 11:45 -0800, Joe Zeff wrote: > > > On 02/24/2018 01:53 AM, Bob Goodwin wrote: > > > > No, a reboot did not do it ... > > > > > > OK, try adding this to .bashrc and source it: > > > > > > alias ls=ls > > > > > > That overrides the default alias that "helpfully" adds the colors. > > > > The canonical way to do this is: > > > > unalias ls > > That was my first suggestion. So I see. I'm intrigued as to why the OP says it didn't work. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, 24 Feb 2018 13:14:49 -0500 Tom H wrote: > On Sat, Feb 24, 2018 at 9:03 AM, bruce wrote: > > > > Have a bunch of files with the basic naming of: > > ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat > > ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat > > etc.. > > > > I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the > > files, renaming the files to the rest of the filename.. > > > > Thought it should be simple using rename > > > > rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat > > > > However, this didn't work... so.. hmm.. > > Is "rename" provided by util-linux or is it a perl-provided script? > > The util-linux syntax is > > rename search_for replace_with > > while the perl-script syntax is > > rename 's/search_for/replace_with/' thanks for the latter sed syntax - good to know on Debian, IINM ... And this: a modern nautilus now does batch renaming of files/folders, it seems ... Regards, -- Wolfgang Pfeiffer ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: More color problems -
On 02/24/2018 01:55 PM, Patrick O'Callaghan wrote: On Sat, 2018-02-24 at 11:45 -0800, Joe Zeff wrote: On 02/24/2018 01:53 AM, Bob Goodwin wrote: No, a reboot did not do it ... OK, try adding this to .bashrc and source it: alias ls=ls That overrides the default alias that "helpfully" adds the colors. The canonical way to do this is: unalias ls That was my first suggestion. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, 2018-02-24 at 09:41 -0900, Fred Erickson wrote: > On Sat, 24 Feb 2018 18:02:39 + > Patrick O'Callaghan wrote: > > ..snip > > > > > > There appears to be 2 different "rename" programs out in the > > > world. The Fedora rename uses a text string for the pattern, but > > > on my Mint box the pattern is a sed-like substitution. > > > Confusing ? > > > > Since this is a Fedora list, that's the one I mean. Don't anything > > about the Mint one. There are also other things like krename etc. > > which are more flexible but harder to use (IMHO). > > > > poc > > There is a GUI tool called 'pyRenamer' that I use on F27 mainly for > renaming photos that is very useful once you get it figured out. > Especially if you have lots of files with lots of different name > patterns. Shows what the change will be before you execute the change > command. Yes. 'dnf search rename' throws up this and several others. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: More color problems -
On Sat, 2018-02-24 at 11:45 -0800, Joe Zeff wrote: > On 02/24/2018 01:53 AM, Bob Goodwin wrote: > > No, a reboot did not do it ... > > OK, try adding this to .bashrc and source it: > > alias ls=ls > > That overrides the default alias that "helpfully" adds the colors. The canonical way to do this is: unalias ls poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: why does virtualbox keep all my old /lib/modules directories around?
On 02/25/18 02:51, Todd Zullinger wrote: > Robert P. J. Day wrote: >> i honestly don't recall how they came to be there, but i rarely >> install anything on my fedora system *not* via an actual .rpm package. > I don't know how Virtualbox works, but perhaps some version > in the past installed via rpm and then helpfully compiled > modules for updated kernels and installed those directly -- > as opposed to how akmods work by generating a kmod package > and installing that? If one installs VirtualBox packaged by rpmfusion then you get akmod-VirtualBox. Other than that, I'm not familiar with the rpmfusion process since I don't use rpmfusion for VBox. I use VirtualBox directly from Oracle. In that case the drivers are built as needed by the vboxdrv.service. I don't know about placement of the drivers in the rpmfusion case, but in the Oracle case they get installed in /lib/modules//`uname -r`/misc. This directory does not exist on a kernel that doesn't have VirtualBox installed. Prior to systemd, I'm pretty sure VirtualBox also used init scripts to determine if/when the modules needed to be built for a running kernel. In the recent past I use to get warning messages when running "dnf update" and a new kernel was being installed and directories/files were being left undeleted. At some point, probably with a new version of dnf, I stopped getting the messagesbut I got so used to them I really didn't take notice. -- A motto of mine is: When in doubt, try it out signature.asc Description: OpenPGP digital signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: samba share without authentication
On Sat, 24 Feb 2018 14:29:36 -0500 Fred Smith wrote: > Instead of putting it all in a batch file, including your credentials > a safer way... I'm doing the equivalent of a public share. Having the credentials in a world readable .bat file on the windows system is no less secure than an actual public share (which they either made impossible or made so obscure it might as well be impossible). P.S. There is no /etc/fstab on windows :-). ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: More color problems -
On 02/24/2018 01:53 AM, Bob Goodwin wrote: No, a reboot did not do it ... OK, try adding this to .bashrc and source it: alias ls=ls That overrides the default alias that "helpfully" adds the colors. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: More color problems -
On 02/24/2018 01:45 AM, Bob Goodwin wrote: That doesn't seem to work, perhaps a reboot is needed? Either close the terminal and open a new one or do this: source .bashrc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: samba share without authentication
On Sat, Feb 24, 2018 at 07:35:06AM -0500, Tom Horsley wrote: > On Sat, 24 Feb 2018 11:24:06 +0100 > François Patte wrote: > > > user > > name and password are required! > > I keep reading this is possible, but ever since > samba 4 came around it seems to be impossible. > I eventually gave up and made a .bat file with > the net command to mount the share with a user > and password hard coded in the .bat file, then > put the .bat file in the startup folder. Instead of putting it all in a batch file, including your credentials a safer way is to put an entry like this in /etc/fstab: //192.168.2.96/public /mounts/syno-public cifs credentials=/root/.smbcred,defaults,uid=,gid=,auto,users,exec,vers=3.0 0 0 i.e., where you use the "credentials=" option, store your credentials in the file you identify in that option, and assign the file permissions like this: ls -l /root/.s* -rw---. 1 root root 36 Feb 5 2017 /root/.smbcred which makes it root readable/writable only. much safer than putting it all in a shellscript. this is on Centos 7-up-to-date, using Samba 4.6.2. the credentials file contents would be of the form: username= password= Oh, and also, the "vers=3.0" forces SMB 3 protocol, which is MUCH less full of holes than are the earlier versions. Depending on the flavor of windows you're connecting to, you may need to relax that to 2 instead of 3. But don't go to version 1, Microsoft has (finally) deprecated it as being too insecure for words. -- Fred Smith -- fre...@fcshome.stoneham.ma.us - "Not everyone who says to me, 'Lord, Lord,' will enter the kingdom of heaven, but only he who does the will of my Father who is in heaven." -- Matthew 7:21 (niv) - ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: why does virtualbox keep all my old /lib/modules directories around?
Robert P. J. Day wrote:
> i honestly don't recall how they came to be there, but i rarely
> install anything on my fedora system *not* via an actual .rpm package.
I don't know how Virtualbox works, but perhaps some version
in the past installed via rpm and then helpfully compiled
modules for updated kernels and installed those directly --
as opposed to how akmods work by generating a kmod package
and installing that?
> so, clearly, kernel removal comes along to remove the corresponding
> /lib/modules directory, finds it still has content, and is forced to
> leave it there. that's annoying.
But much better than rpm removing directories that are not
empty and contain files which are not part of any package,
of couse. :)
> is there any option for kernel removal to at least warn
> that it can't delete the /lib/modules directory?
I'm not aware of any such options. That would have to be
done in rpm, I believe. And then it would likely warn far
more often than you'd want.
You could write a quick script which looked for orphaned
files under /lib/modules (and optionally cleaned them up)
fairly easily.
You do have to be careful to not remove some files generated
by depmod (which kmod packages call in their
%post scriptlets, at least).
Running something like this occasionally should help locate
any cruft:
find /lib/modules/ ! -name 'modules.*' -print0 | \
xargs -r0 rpm -qf | awk '/is not owned/ {print $2}'
That's not perfect by any means. The awk portion is
particularly broken if the listed files contain spaces. I
don't know of a way to have rpm output only the filename or
use a different separator.
If I was going to really use such a script I'd look at the
python rpm bindings most likely.
Short of that, I'd tighten the unowned filename extraction
in one way or another. Matching the full line and stripping
out the leading 'file ' and trailing 'is not owned by any
package' is probably the simplest method -- not necessarily
done with awk. It could be grep piped to sed, perl, or
whatever suits your tastes.
--
Todd
~~
Don't take life seriously, you'll never get out alive.
signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, 24 Feb 2018 18:02:39 + Patrick O'Callaghan wrote: ..snip > > > > There appears to be 2 different "rename" programs out in the > > world. The Fedora rename uses a text string for the pattern, but > > on my Mint box the pattern is a sed-like substitution. > > Confusing ? > > Since this is a Fedora list, that's the one I mean. Don't anything > about the Mint one. There are also other things like krename etc. > which are more flexible but harder to use (IMHO). > > poc There is a GUI tool called 'pyRenamer' that I use on F27 mainly for renaming photos that is very useful once you get it figured out. Especially if you have lots of files with lots of different name patterns. Shows what the change will be before you execute the change command. Fred ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, Feb 24, 2018 at 9:03 AM, bruce wrote: > > Have a bunch of files with the basic naming of: > ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat > ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat > etc.. > > I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the > files, renaming the files to the rest of the filename.. > > Thought it should be simple using rename > > rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat > > However, this didn't work... so.. hmm.. Is "rename" provided by util-linux or is it a perl-provided script? The util-linux syntax is rename search_for replace_with while the perl-script syntax is rename 's/search_for/replace_with/' ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: samba share without authentication
On 02/24/2018 02:24 AM, François Patte wrote: I read a lot of smb.conf that are supposed to configure samba to share a folder without authentication (ie. everybody connected to the LAN can access this folder) but all these config files are wrong... ie. when I try to connect to the samba server (f27), from a windows computer, user name and password are required! In the global section, you should set "map to guest = Bad User", and in the share or printer spool section, set "guest ok = Yes". If Windows prompts for credentials, enter nothing. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, 2018-02-24 at 08:55 -0800, John Wendel wrote: > On 02/24/2018 08:38 AM, Patrick O'Callaghan wrote: > > On Sat, 2018-02-24 at 09:03 -0500, bruce wrote: > > > Hi. > > > > > > Have a bunch of files with the basic naming of: > > > ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat > > > ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat > > > etc.. > > > > > > I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the > > > files, renaming the files to the rest of the filename.. > > > > > > Thought it should be simple using rename > > > > > > rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat > > > > Read the man page again. The pattern is just a text string, not a regex > > or sed-type command. > > > > poc > > ___ > > users mailing list -- users@lists.fedoraproject.org > > To unsubscribe send an email to users-le...@lists.fedoraproject.org > > > > > There appears to be 2 different "rename" programs out in the world. The > Fedora rename uses a text string for the pattern, but on my Mint box the > pattern is a sed-like substitution. Confusing ? Since this is a Fedora list, that's the one I mean. Don't anything about the Mint one. There are also other things like krename etc. which are more flexible but harder to use (IMHO). poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: why does virtualbox keep all my old /lib/modules directories around?
On Sat, 24 Feb 2018, Todd Zullinger wrote:
> Ed Greshko wrote:
> > On 02/24/18 15:32, Robert P. J. Day wrote:
> >> not sure why i never noticed this before, but even though
> >> updating my fedora box keeps only the last three versions of the
> >> kernel, i have a couple dozen /lib/modules directories each
> >> representing an older version of the kernel going back to
> >> 4.11.12, and when i examine all those old directories, they
> >> contain nothing but:
> >>
> >> 4.11.12-200.fc25.x86_64
> >> │ └── misc
> >> │ ├── vboxdrv.ko
> >> │ ├── vboxnetadp.ko
> >> │ ├── vboxnetflt.ko
> >> │ └── vboxpci.ko
> >>
> >> ... etc etc ...
> >>
> >> i'm sure i'm safe to manually remove all those older
> >> /lib/modules, but should i be surprised that they're even there?
> >> is there something i can configure about virtualbox to not have
> >> it lock those old directories in place?
> >
> > Sounds more like the kernel removal process than anything related
> > to virtualbox.
>
> It depends on how the Virtualbox modules are installed. If they're
> via kmod/akmod packages, then when the corresponding kernel is
> removed the kmod-vbox-${kernel_uname} package should be removed,
> removing the files it installed.
i honestly don't recall how they came to be there, but i rarely
install anything on my fedora system *not* via an actual .rpm package.
> I suspect that the vbox modules weren't installed via an rpm package
> -- or if they were, those packages lack a proper requirement on the
> kernel version they're built for, which leaves this cruft.
>
> Running:
>
> $ rpm -qf /lib/modules/4.11.12-200.fc25.x86_64/misc/vboxdrv.ko
>
> would be useful in determining whether they're owned by any package.
> We know they don't come from the kernel rpm, so it's not it's job to
> clean them up (and it would be wrong if it did, of course).
totally predictably:
$ rpm -qf /lib/modules/4.11.12-200.fc25.x86_64/misc/vboxdrv.ko
file /lib/modules/4.11.12-200.fc25.x86_64/misc/vboxdrv.ko is not owned by any
package
$
so, clearly, kernel removal comes along to remove the corresponding
/lib/modules directory, finds it still has content, and is forced to
leave it there. that's annoying. is there any option for kernel
removal to at least warn that it can't delete the /lib/modules
directory? not sure why i never noticed this before, i'll try to
recall how virtualbox ended up on this system.
rday___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On 02/24/2018 08:38 AM, Patrick O'Callaghan wrote: On Sat, 2018-02-24 at 09:03 -0500, bruce wrote: Hi. Have a bunch of files with the basic naming of: ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat etc.. I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the files, renaming the files to the rest of the filename.. Thought it should be simple using rename rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat Read the man page again. The pattern is just a text string, not a regex or sed-type command. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org There appears to be 2 different "rename" programs out in the world. The Fedora rename uses a text string for the pattern, but on my Mint box the pattern is a sed-like substitution. Confusing ? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, 2018-02-24 at 16:38 +, Patrick O'Callaghan wrote: > On Sat, 2018-02-24 at 09:03 -0500, bruce wrote: > > Hi. > > > > Have a bunch of files with the basic naming of: > > ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat > > ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat > > etc.. > > > > I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the > > files, renaming the files to the rest of the filename.. > > > > Thought it should be simple using rename > > > > rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat > > Read the man page again. The pattern is just a text string, not a regex > or sed-type command. In fact the man page is very misleading as it uses the term 'expression' without any explanation. All the same, it is in fact only a text string. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, 2018-02-24 at 09:03 -0500, bruce wrote: > Hi. > > Have a bunch of files with the basic naming of: > ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat > ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat > etc.. > > I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the > files, renaming the files to the rest of the filename.. > > Thought it should be simple using rename > > rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat Read the man page again. The pattern is just a text string, not a regex or sed-type command. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, 24 Feb 2018 09:03:09 -0500 bruce wrote: > Hi. > > Have a bunch of files with the basic naming of: > ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat > ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat > etc.. > > I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the > files, renaming the files to the rest of the filename.. > > Thought it should be simple using rename > > rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat > > However, this didn't work... so.. hmm.. > > How would you guys solve this? > > SO has a bunch of different solns as well. > > thanks... This worked here with the F26 version of 'rename': it seems part of the util-linux package here: First a cold-run on the files you want to change with the "-n" switch. Without changing anything: % rename -nv 'ztcloud_nfs_parseztaa_1__' '' * If rename shows what it will do, and you're fine with it, the real thing. So leave away "-n": % rename -v 'ztcloud_nfs_parseztaa_1__' '' * I like this little tool, and sometimes I fight with it to do even more time-saving things with it. But I think the fight it needs is worth the time it takes. Oh yes: and sometimes 'rename' wins ... ;) Good luck -- Wolfgang Pfeiffer ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: why does virtualbox keep all my old /lib/modules directories around?
Ed Greshko wrote:
> On 02/24/18 15:32, Robert P. J. Day wrote:
>> not sure why i never noticed this before, but even though updating
>> my fedora box keeps only the last three versions of the kernel, i have
>> a couple dozen /lib/modules directories each representing an older
>> version of the kernel going back to 4.11.12, and when i examine all
>> those old directories, they contain nothing but:
>>
>> 4.11.12-200.fc25.x86_64
>> │ └── misc
>> │ ├── vboxdrv.ko
>> │ ├── vboxnetadp.ko
>> │ ├── vboxnetflt.ko
>> │ └── vboxpci.ko
>>
>> ... etc etc ...
>>
>> i'm sure i'm safe to manually remove all those older /lib/modules,
>> but should i be surprised that they're even there? is there something
>> i can configure about virtualbox to not have it lock those old
>> directories in place?
>
> Sounds more like the kernel removal process than anything related to
> virtualbox.
It depends on how the Virtualbox modules are installed. If
they're via kmod/akmod packages, then when the corresponding
kernel is removed the kmod-vbox-${kernel_uname} package
should be removed, removing the files it installed.
I suspect that the vbox modules weren't installed via an rpm
package -- or if they were, those packages lack a proper
requirement on the kernel version they're built for, which
leaves this cruft.
Running:
$ rpm -qf /lib/modules/4.11.12-200.fc25.x86_64/misc/vboxdrv.ko
would be useful in determining whether they're owned by any
package. We know they don't come from the kernel rpm, so
it's not it's job to clean them up (and it would be wrong if
it did, of course).
--
Todd
~~
A fool's brain digests philosophy into folly, science into
superstition, and art into pedantry. Hence University education.
-- George Bernard Shaw
signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
Hey guys...
Thanks for the reply.
The rename cmd actually works. I just screwed it up, and used the
syntax for Debian which is the regex.
For Fed/Centos et al
rename foo cat files -- works as expected!
Thanks!
On Sat, Feb 24, 2018 at 10:46 AM, Jon LaBadie wrote:
> On Sat, Feb 24, 2018 at 10:46:46PM +0800, Ed Greshko wrote:
>> On 02/24/18 22:42, Robert P. J. Day wrote:
>> > On Sat, 24 Feb 2018, Ed Greshko wrote:
>> >
>> >> On 02/24/18 22:03, bruce wrote:
>> >>> Hi.
>> >>>
>> >>> Have a bunch of files with the basic naming of:
>> >>> ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat
>> >>> ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat
>> >>> etc..
>> >>>
>> >>> I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the
>> >>> files, renaming the files to the rest of the filename..
>> >>>
>> >>> Thought it should be simple using rename
>> >>>
>> >>> rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat
>> >>>
>> >>> However, this didn't work... so.. hmm..
>> >>>
>> >>> How would you guys solve this?
>> >>>
>> >>> SO has a bunch of different solns as well.
>> >> If I understand correctly you want
>> >> ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat
>> >> renamed to aa_1__WGS_7500_001__parse.dat, etc?
>> >> And all the files follow the pattern with the same length?
>> >>
>> >> If so, the simple script
>> >>
>> >> #!/bin/bash
>> >>
>> >> for file in *dat
>> >>
>> >> do
>> >> name=`echo $file | cut -c20-48`
>> >> mv $file $name
>> >> done
>> >>
>> >> does it.
>> > fedora has a "rename" command that would seem to be designed for
>> > just this sort of thing.
>> >
>>
>> I've not used "rename". And the OP said what he tried didn't work. So, you
>> have the
>> answer or you are just saying you don't like my script?
>>
> The thing I don't like is your script has the potential of
> modifying unintended files. I'd use one of the shell's
> variable expansion features to strip just what was unwanted.
>
> for f in *.dat
> do
> echo mv $f ${f/zt...aa/aa}
> done
>
> Fill in the ... with the actual chars.
> The "echo" gives a test run to see what will be done with no echo.
> mv may complain about ",dat" files that don't match the "zt...aa"
> pattern, "original and new name identical.
>
> jon
>>
>> --
>> A motto of mine is: When in doubt, try it out
>>
>
>
>
>
>> ___
>> users mailing list -- users@lists.fedoraproject.org
>> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>
End of included message <<<
>
> --
> Jon H. LaBadie jo...@jgcomp.com
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, Feb 24, 2018 at 10:46:46PM +0800, Ed Greshko wrote:
> On 02/24/18 22:42, Robert P. J. Day wrote:
> > On Sat, 24 Feb 2018, Ed Greshko wrote:
> >
> >> On 02/24/18 22:03, bruce wrote:
> >>> Hi.
> >>>
> >>> Have a bunch of files with the basic naming of:
> >>> ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat
> >>> ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat
> >>> etc..
> >>>
> >>> I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the
> >>> files, renaming the files to the rest of the filename..
> >>>
> >>> Thought it should be simple using rename
> >>>
> >>> rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat
> >>>
> >>> However, this didn't work... so.. hmm..
> >>>
> >>> How would you guys solve this?
> >>>
> >>> SO has a bunch of different solns as well.
> >> If I understand correctly you want
> >> ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat
> >> renamed to aa_1__WGS_7500_001__parse.dat, etc?
> >> And all the files follow the pattern with the same length?
> >>
> >> If so, the simple script
> >>
> >> #!/bin/bash
> >>
> >> for file in *dat
> >>
> >> do
> >> name=`echo $file | cut -c20-48`
> >> mv $file $name
> >> done
> >>
> >> does it.
> > fedora has a "rename" command that would seem to be designed for
> > just this sort of thing.
> >
>
> I've not used "rename". And the OP said what he tried didn't work. So, you
> have the
> answer or you are just saying you don't like my script?
>
The thing I don't like is your script has the potential of
modifying unintended files. I'd use one of the shell's
variable expansion features to strip just what was unwanted.
for f in *.dat
do
echo mv $f ${f/zt...aa/aa}
done
Fill in the ... with the actual chars.
The "echo" gives a test run to see what will be done with no echo.
mv may complain about ",dat" files that don't match the "zt...aa"
pattern, "original and new name identical.
jon
>
> --
> A motto of mine is: When in doubt, try it out
>
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>>> End of included message <<<
--
Jon H. LaBadie jo...@jgcomp.com
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: More color problems -
On 02/24/18 07:24, ja wrote: I would like to eliminate all [or change some] colors when I list files with xfce4-terminal. maybe alias this ? ls --color=never "Using color to distinguish file types is disabled both by default and with --color=never. With --color=auto, ls emits color codes only when standard output is connected to a terminal. The LS_COLORS environment variable can change the settings. Use the dircolors command to set it." That eliminates color but displays only directories and in my case three .csv files? However "export LS_COLORS=none" does seem to do what I want, white text only. My color perception is impaired and I have a lot of difficulty with anything but white text although I do manage if necessary. Thanks, Bob -- Bob Goodwin - Zuni, Virginia, USA http://www.qrz.com/db/W2BOD box10 FEDORA-27/64bit LINUX XFCE Fastmail POP3 ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, 2018-02-24 at 09:03 -0500, bruce wrote: > Hi. > > Have a bunch of files with the basic naming of: > ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat > ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat > etc.. > > I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the > files, renaming the files to the rest of the filename.. > > Thought it should be simple using rename > > rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat > > However, this didn't work... so.. hmm.. > > How would you guys solve this? I think the language might be: rename 'ztcloud_nfs_parseztaa' 'aa' zt*.dat -- Doug H. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On 02/24/18 22:42, Robert P. J. Day wrote: > On Sat, 24 Feb 2018, Ed Greshko wrote: > >> On 02/24/18 22:03, bruce wrote: >>> Hi. >>> >>> Have a bunch of files with the basic naming of: >>> ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat >>> ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat >>> etc.. >>> >>> I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the >>> files, renaming the files to the rest of the filename.. >>> >>> Thought it should be simple using rename >>> >>> rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat >>> >>> However, this didn't work... so.. hmm.. >>> >>> How would you guys solve this? >>> >>> SO has a bunch of different solns as well. >> If I understand correctly you want >> ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat >> renamed to aa_1__WGS_7500_001__parse.dat, etc? >> And all the files follow the pattern with the same length? >> >> If so, the simple script >> >> #!/bin/bash >> >> for file in *dat >> >> do >> name=`echo $file | cut -c20-48` >> mv $file $name >> done >> >> does it. > fedora has a "rename" command that would seem to be designed for > just this sort of thing. > I've not used "rename". And the OP said what he tried didn't work. So, you have the answer or you are just saying you don't like my script? -- A motto of mine is: When in doubt, try it out signature.asc Description: OpenPGP digital signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On Sat, 24 Feb 2018, Ed Greshko wrote: > On 02/24/18 22:03, bruce wrote: > > Hi. > > > > Have a bunch of files with the basic naming of: > > ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat > > ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat > > etc.. > > > > I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the > > files, renaming the files to the rest of the filename.. > > > > Thought it should be simple using rename > > > > rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat > > > > However, this didn't work... so.. hmm.. > > > > How would you guys solve this? > > > > SO has a bunch of different solns as well. > > If I understand correctly you want > ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat > renamed to aa_1__WGS_7500_001__parse.dat, etc? > And all the files follow the pattern with the same length? > > If so, the simple script > > #!/bin/bash > > for file in *dat > > do > name=`echo $file | cut -c20-48` > mv $file $name > done > > does it. fedora has a "rename" command that would seem to be designed for just this sort of thing. rday ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: basic issue/question -- renaming in mass a bunch of files
On 02/24/18 22:03, bruce wrote: > Hi. > > Have a bunch of files with the basic naming of: > ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat > ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat > etc.. > > I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the > files, renaming the files to the rest of the filename.. > > Thought it should be simple using rename > > rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat > > However, this didn't work... so.. hmm.. > > How would you guys solve this? > > SO has a bunch of different solns as well. If I understand correctly you want ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat renamed to aa_1__WGS_7500_001__parse.dat, etc? And all the files follow the pattern with the same length? If so, the simple script #!/bin/bash for file in *dat do name=`echo $file | cut -c20-48` mv $file $name done does it. -- A motto of mine is: When in doubt, try it out signature.asc Description: OpenPGP digital signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
basic issue/question -- renaming in mass a bunch of files
Hi. Have a bunch of files with the basic naming of: ztcloud_nfs_parseztaa_1__WGS_7500_001__parse.dat ztcloud_nfs_parseztaa_1__WGS_7500_002__parse.dat etc.. I'd like to simply remove the 1st part ztcloud_nfs_parsezt from the files, renaming the files to the rest of the filename.. Thought it should be simple using rename rename 's/ztcloud_nfs_parseztaa/aa/' zt*.dat However, this didn't work... so.. hmm.. How would you guys solve this? SO has a bunch of different solns as well. thanks... ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: Nvidia Module Tainting Kernel
On Sat, 2018-02-24 at 15:43 +1100, Stephen Morris wrote: > Are all these taint messages, and all the reasons for a taint message > being produced saying that if we have to build our own drivers into the > kernel to be able to use our hardware, and hence put us into the > situation of potentially not getting support for kernel defects if any > are encountered, that we shouldn't be using linux? If you encounter a kernel defect, how can it be debugged if part of the kernel is not available? That's what tainting amounts to. IIRC you've said that you compile the Nvidia modules. What you are actually doing is compiling code (the dkms system) that enables Nvidia's binary blobs to be linked as modules into the Linux kernel. You don't (unless you work for Nvidia) have the source code of those blobs. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: samba share without authentication
On Sat, 24 Feb 2018 11:24:06 +0100 François Patte wrote: > user > name and password are required! I keep reading this is possible, but ever since samba 4 came around it seems to be impossible. I eventually gave up and made a .bat file with the net command to mount the share with a user and password hard coded in the .bat file, then put the .bat file in the startup folder. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: More color problems -
On Sat, 2018-02-24 at 04:53 -0500, Bob Goodwin wrote: > On 02/24/18 04:45, Bob Goodwin wrote: > > On 02/24/18 04:31, Joe Zeff wrote: > > > > I would like to eliminate all [or change some] colors when I list > > > > files with xfce4-terminal. I know this has been discussed before but > > > > I haven't found much in my notes? > > > > > > > > How can I change them to white? I keep the display set for white > > > > text on a black background. > > > > > > add this line to .bashrc: > > > > > > unalias ls > > > > . > > That doesn't seem to work, perhaps a reboot is needed? > > > > . > No, a reboot did not do it ... > > maybe alias this ? ls --color=never "Using color to distinguish file types is disabled both by default and with --color=never. With --color=auto, ls emits color codes only when standard output is connected to a terminal. The LS_COLORS environment variable can change the settings. Use the dircolors command to set it." ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: Nvidia Module Tainting Kernel
On 02/24/18 12:43, Stephen Morris wrote: > Thanks Ed. Is there any documentation anywhere on what each bit represents? You mean other than the URL I've supplied at kernel.org and the comments within tainted.c ? > > > With bit 13 being set reflecting the loading of an unsigned module into a > kernel > supporting module signatures, is that because the kernel has been designed for > secure boot, and will turning on secure boot resolve the signing issue? Probably not, since 13 and 12 are probably a pair in your case. > Are all these taint messages, and all the reasons for a taint message being > produced saying that if we have to build our own drivers into the kernel to > be able > to use our hardware, and hence put us into the situation of potentially not > getting > support for kernel defects if any are encountered, that we shouldn't be using > linux? No. It is just saying that in the unlikely event you run into a kernel problem and you want to report it you should first check to see if others have the problem and/or try to reproduce it a non-tainted environment. Like running whatever you thought caused the problem in a QEMU/KVM environment. I don't think it is very likely that you're going to run into a kernel issue that needs reporting. I've never had a kernel crash except years ago when integrating the nVidia drivers was a DYI project. -- A motto of mine is: When in doubt, try it out signature.asc Description: OpenPGP digital signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: why does virtualbox keep all my old /lib/modules directories around?
On 02/24/18 15:32, Robert P. J. Day wrote: > not sure why i never noticed this before, but even though updating > my fedora box keeps only the last three versions of the kernel, i have > a couple dozen /lib/modules directories each representing an older > version of the kernel going back to 4.11.12, and when i examine all > those old directories, they contain nothing but: > > 4.11.12-200.fc25.x86_64 > │ └── misc > │ ├── vboxdrv.ko > │ ├── vboxnetadp.ko > │ ├── vboxnetflt.ko > │ └── vboxpci.ko > > ... etc etc ... > > i'm sure i'm safe to manually remove all those older /lib/modules, > but should i be surprised that they're even there? is there something > i can configure about virtualbox to not have it lock those old > directories in place? Sounds more like the kernel removal process than anything related to virtualbox. As a test, you could manually remove the oldest of the 3 kernels on your system and see what that results in. -- A motto of mine is: When in doubt, try it out signature.asc Description: OpenPGP digital signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
samba share without authentication
Bonjour, I read a lot of smb.conf that are supposed to configure samba to share a folder without authentication (ie. everybody connected to the LAN can access this folder) but all these config files are wrong... ie. when I try to connect to the samba server (f27), from a windows computer, user name and password are required! I want to do the same for the printer connected to the samba server: everyone connected on the LAN can use this printer without user/password... Is that possible? And how? Thank you. -- François Patte UFR de mathématiques et informatique Laboratoire CNRS MAP5, UMR 8145 Université Paris Descartes 45, rue des Saints Pères F-75270 Paris Cedex 06 Tél. +33 (0)6 7892 5822 http://www.math-info.univ-paris5.fr/~patte signature.asc Description: OpenPGP digital signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: More color problems -
On 02/24/18 04:45, Bob Goodwin wrote: On 02/24/18 04:31, Joe Zeff wrote: I would like to eliminate all [or change some] colors when I list files with xfce4-terminal. I know this has been discussed before but I haven't found much in my notes? How can I change them to white? I keep the display set for white text on a black background. add this line to .bashrc: unalias ls . That doesn't seem to work, perhaps a reboot is needed? . No, a reboot did not do it ... -- Bob Goodwin - Zuni, Virginia, USA http://www.qrz.com/db/W2BOD box10 FEDORA-27/64bit LINUX XFCE Fastmail POP3 ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: More color problems -
On 02/24/18 04:31, Joe Zeff wrote: I would like to eliminate all [or change some] colors when I list files with xfce4-terminal. I know this has been discussed before but I haven't found much in my notes? How can I change them to white? I keep the display set for white text on a black background. add this line to .bashrc: unalias ls . That doesn't seem to work, perhaps a reboot is needed? -- Bob Goodwin - Zuni, Virginia, USA http://www.qrz.com/db/W2BOD box10 FEDORA-27/64bit LINUX XFCE Fastmail POP3 ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: More olor problems -
On 02/24/2018 01:10 AM, Bob Goodwin wrote: I would like toeliminate all [or change some] colors when I list files with xfce4-terminal. I know this has been discussed before but I haven't found much in my notes? How can I change them to white? I keep the display set for white text on a black background. add this line to .bashrc: unalias ls ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: More Color problems -
On 02/24/18 04:10, Bob Goodwin wrote: I would like to eliminate all [or change some] colors when I list files with xfce4-terminal. I know this has been discussed before but I haven't found much in my notes? How can I change them to white? I keep the display set for white text on a black background. Bob -- Bob Goodwin - Zuni, Virginia, USA http://www.qrz.com/db/W2BOD box10 FEDORA-27/64bit LINUX XFCE Fastmail POP3 ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
More olor problems -
I would like toeliminate all [or change some] colors when I list files with xfce4-terminal. I know this has been discussed before but I haven't found much in my notes? How can I change them to white? I keep the display set for white text on a black background. Bob -- Bob Goodwin - Zuni, Virginia, USA http://www.qrz.com/db/W2BOD box10 FEDORA-27/64bit LINUX XFCE Fastmail POP3 ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
