On 7/14/24 00:57, Richard Bostrom wrote:
Executing this script halts it after the tar with the following message.
--
#!/bin/sh
tar -zcvf bak.tar.gz /home/user/Documents &&
gpg -r backup@user.local -e bak.tar.gz &&
rm -rf bak.tar.gz &&
rsync -vac --delete /home/user/Documents/bak.tar.gz.gpg
Richard Bostrom (12024-07-14):
> tar -zcvf bak.tar.gz /home/user/Documents &&
Information missing: what is the current directory.
> gpg -r backup@user.local -e bak.tar.gz &&
> rm -rf bak.tar.gz &&
> rsync -vac --delete /home/user/Documents/bak.tar.gz.gpg /media/user/6548-2136
> & -rf
Executing this script halts it after the tar with the following message.
--
#!/bin/sh
tar -zcvf bak.tar.gz /home/user/Documents &&
gpg -r backup@user.local -e bak.tar.gz &&
rm -rf bak.tar.gz &&
rsync -vac --delete /home/user/Documents/bak.tar.gz.gpg /media/user/6548-2136
& -rf bak.tar.gz.gpg
вс, 30 июн. 2024 г. в 17:23, Uno Qualsiasi :
>
> Buongiorno vi contatto per segnalare un problema nel processo di
> installazione di debian 12.5.0 dvd iso 32 bit, ossia che quando arriva al
> momento di eseguire “grub-install” su disco primario mi fa errore. Su
> qualsiasi pf 32 bit lo provi è
On 30 Jun 2024 09:11 +0200, from unoqualsiasi...@icloud.com (Uno Qualsiasi):
> Buongiorno vi contatto per segnalare un problema nel processo di
> installazione di debian 12.5.0 dvd iso 32 bit, ossia che quando arriva al
> momento di eseguire “grub-install” su disco primario mi fa errore. Su
>
Buongiorno vi contatto per segnalare un problema nel processo di installazione
di debian 12.5.0 dvd iso 32 bit, ossia che quando arriva al momento di eseguire
“grub-install” su disco primario mi fa errore. Su qualsiasi pf 32 bit lo provi
è fa lo stesso problema.
Inviato da Uno qualsiasi
Daniel Rodriguez writes:
> The solution of the post to this issue is to update the kernel from
> 6.1.0-13 -> 6.1.0.18; however, my kernel is a later version:
> 6.1.0-21-amd64, so I am stuck for solving this issue. Do you have any
> idea about what may be happening and/or how to solve it?
I
gt; [/usr/src/linux-headers-6.1.0-21-common/scripts/Makefile.modfinal:63:
> /var/lib/dkms/nvidia-current/525.147.05/build/nvidia-peermem.ko] Error 127
> make[3]: *** Deleting file
> '/var/lib/dkms/nvidia-current/525.147.05/build/nvidia-peermem.ko'
>
The post
<https://forums.debian.ne
On Thu, Jun 13, 2024 at 06:59:49AM +0200, Kamil Jońca wrote:
> to...@tuxteam.de writes:
[...]
> > and of course, if you are using a desktop environment and NetworkManager
> > or systemd-networkd, it's probably better to go with the flow and let
> > them do.
>
> About year ago none of them was
to...@tuxteam.de writes:
> On Thu, Jun 13, 2024 at 06:30:27AM +0200, to...@tuxteam.de wrote:
>
> [following up on myself, bad style, I know]
>
>> For my laptop, I very much prefer to say "sudo ifup eth0" than to
>> say "sudo ifup en0ps&&@*#!☠" thankyouverymuch :)
>
> and of course, if you are
On Thu, Jun 13, 2024 at 06:30:27AM +0200, to...@tuxteam.de wrote:
[following up on myself, bad style, I know]
> For my laptop, I very much prefer to say "sudo ifup eth0" than to
> say "sudo ifup en0ps&&@*#!☠" thankyouverymuch :)
and of course, if you are using a desktop environment and
On Wed, Jun 12, 2024 at 03:16:41PM -0400, Greg Wooledge wrote:
> On Wed, Jun 12, 2024 at 09:01:44PM +0200, to...@tuxteam.de wrote:
[...]
> > Mine loks like this:
> >
> > GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"
>
> People who are thinking of doing this should take a moment to
So question is,
> can this be disabled on Proxmox? But with this hint, it should be
> easy enough to figure out if this can be deactivated on the affected
> systems, and if not the bug reports must be against these issues, as
> Debian itself doesn't do such things. If it is an issue
On Wed, Jun 12, 2024 at 09:01:44PM +0200, to...@tuxteam.de wrote:
> No need. You can have your traditional names (I do). Just add
> "net.ifnames=0" (if necessry separated by a space, should
> other stuff be already there) to your GRUB_CMDLINE_LINUX_DEFAULT
> in your /etc/default/grub, then ru
On Wed, Jun 12, 2024 at 02:30:40PM -0400, Roy J. Tellason, Sr. wrote:
> On Wednesday 12 June 2024 06:54:54 am Richard wrote:
> > But also, just
> > searching the web for this topic, you should have come across this
> > answering your questions: https://wiki.debian.org/NetworkInterfaceNames
> >
>
On Wednesday 12 June 2024 06:54:54 am Richard wrote:
> But also, just
> searching the web for this topic, you should have come across this
> answering your questions: https://wiki.debian.org/NetworkInterfaceNames
>
Wow. Just wow...
That sort of thing just drives me crazy! :-)
I can see
on Proxmox? But with this hint, it should be easy enough to figure
out if this can be deactivated on the affected systems, and if not the bug
reports must be against these issues, as Debian itself doesn't do such
things. If it is an issue with Debian preventing the disablement, the devs
need to talk
to take this up with the upstream devs themselves, so by the
> time Trixie is being released, it may already be included.
>
> But besides that, what you describe in the first link sounds to me not like a
> bug, but as a well thought-through decision. Network adapter names like eth0
>
is being released, it may already be included.
But besides that, what you describe in the first link sounds to me not like
a bug, but as a well thought-through decision. Network adapter names like
eth0 have been dropped with Debian 11 (I think, maybe even 10). So don't
get your hopes up too high to ever
Hello,
This bug, or a close relative, has already been reported in
https://github.com/raspberrypi/bookworm-feedback/issues/239
as 'Predictable network names broken for ASIX USB ethernet in kernel 6.6.20'
I added a comment reporting my experience in Proxmox here:
https://github.com/raspberrypi
Gustavo, bom dia!
Posso estar enganado, mas ACHO que você esta usando o layout errado. Realmente
como você mencionou, utilizando "´ + c" no layout "English (US, alt. intl.)" o
resultado será "ć".
Para você utilizar o "ç" é necessário utilizar o layout "English (US, intl.,
with dead keys)" e
Olá,
Procurei por formas de reportar essa ocorrência no site do Debian, e vi que
era recomendado mandar um e-mail para problemas em que o pacote causador é
desconhecido. Espero que haja alguma explicação.
Esse é um problema que eu venho tendo ultimamente. Eu sempre adorei a
instalação em DVD,
uld be a fix for this or at least a way to handle this case with a much
> clearer error message. So I'll probably open a bug report for the package
> and the maintainer can decide if that should be forwarded upstream. Such a
> rather trivial case shouldn't be resulting in such fatal errors.
Th
On 26/04/2024 12:56, David Wright wrote:
On Fri 26 Apr 2024 at 11:27:24 (+0900), John Crawley wrote:
Innocent question: what difference does the comment make vs just ending the
file with an empty line?
Nothing for the computer, but visibility for me.
Say you print the file on paper. All you
On 26/04/2024 10:56, David Wright wrote:
Editor examples: a windowed emacs buffer has a ≣ decoration at the
extreme left edge after the last line of text, so that you can
distinguish an absence of lines from empty lines.
Perhaps that decoration should be explicitly enabled. However it
ramfs can't handle the case that crypttab ends in the
> > > line
> > > of the last entry and not in a new line character. I think there either
> > > should be a fix for this or at least a way to handle this case with a much
> > > clearer error message. So I'll probably
. I think there either
should be a fix for this or at least a way to handle this case with a much
clearer error message. So I'll probably open a bug report for the package
and the maintainer can decide if that should be forwarded upstream. Such a
rather trivial case shouldn't be resulting
uld be a fix for this or at least a way to handle this case with a much
> clearer error message. So I'll probably open a bug report for the package
> and the maintainer can decide if that should be forwarded upstream. Such a
> rather trivial case shouldn't be resulting in such fat
with a much
clearer error message. So I'll probably open a bug report for the package
and the maintainer can decide if that should be forwarded upstream. Such a
rather trivial case shouldn't be resulting in such fatal errors.
Best
Richard
On Wed, Apr 24, 2024, 14:23 Michel Verdier wrote:
> On 2
Hello Hans,
this is exactly what I did. To be precise, I followed this guide [1], with
the difference that instead of "crypt" I used the actual name, luks-
(Disks thanksfully shows everything relevant). It's not the first time I'm
doing this. Yet I experience the errors mentioned. Sure, I'm not
gt; luks,keyscript=/bin/cat
initramfs extract line from /etc/crypttab to create its own crypttab
as you have seen in main/cryptroot/crypttab, and only for rootfs, not for
swap
> Now, is this a bug in the package or am I missing something? And how do I
> create a working initramfs now?
swap
Am Dienstag, 23. April 2024, 22:26:17 CEST schrieb Richard:
Hi Richard,
this is, what I am doing when this happens:
1. booting into a live system (any new is working, I prefer kali-linux)
2. If you are using encrypted filesystems, open it. But you have to name it
like it is named in /
e-initramfs -ck all" from
there. But now it even refuses to find the root partition in crypttab.
Now, is this a bug in the package or am I missing something? And how do I
create a working initramfs now?
Best
Richard
> For what I understood the problem was fixed in 6.8, but I'm using
> debian 12 that will never use that so much new kernel I guess, could
> you help me to report officially the bug so that the upstream channel
> will correct it by the 6.1.0-22 version ?
Bookwom backports has linux-ima
For what I understood the problem was fixed in 6.8, but I'm using debian 12
that will never use that so much new kernel I guess, could you help me to
report officially the bug so that the upstream channel will correct it by
the 6.1.0-22 version ?
Thank you very much!
Hola,
doncs això que sembla que aquest "bug" torna a estar present.
https://lists.debian.org/debian-kernel/2014/01/msg00218.html
M'estic barallant amb una arrencada dual d'una linkat i una debian totes
dues amb les particions arrel i swap xifrades.
Per no haver de posar dues
On 2 Apr 2024 10:27 +0200, from jch...@student.ethz.ch (Jonathan Chung):
> Can someone help me to file a bug report?
https://www.debian.org/Bugs/Reporting
--
Michael Kjörling https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
effort in getting to grips with this bug
>>> (actually multiple bugs), and it looks like a fix may be forthcoming,
>>> though not sure at the time of writing if there may be some further
>>> polishing first
>>>
>>> https://github.com/openzfs/zfs/pull/16019
On 3/25/24 15:05, Gareth Evans wrote:
On Fri 22/03/2024 at 21:01, Gareth Evans wrote:
As anyone interested can see from the ref to #15933 in the below, there seems
to have been considerable effort in getting to grips with this bug (actually
multiple bugs), and it looks like a fix may
On Fri 22/03/2024 at 21:01, Gareth Evans wrote:
> As anyone interested can see from the ref to #15933 in the below, there seems
> to have been considerable effort in getting to grips with this bug (actually
> multiple bugs), and it looks like a fix may be forthcoming, though
have tested
> extensively, considered the issue closed after upgrade to openzfs 2.2.2
>
> https://bugs.gentoo.org/917224#c26
>
> I wonder if the 2.2.3 issue is similar/related, or perhaps there are multiple
> triggers.
>
> Watching with interest.
>
> Best wishes,
> Ga
package.
Thanks for you help.
apt-file shows au0828.ko comes in the linux-image-* packages. So report
the bug for the one you use.
Hi,
I have a possible kernel regression for a usb-dvb tuner card. I know
the error in dmesg points to kernel : au0828 but I am not sure what
package this belongs to. I think it belongs to v4l(video for linux) but
I am still not sure what specific v4l package.
Thanks for you help.
Hi,
Since the upgrade of the Pango library to 1.52 in Debian/unstable, I'm
seeing an annoying bug in gnuplot with the wxt terminal. The issue can
be reproduced with the following command:
echo 'set terminal wxt; plot x' | gnuplot -persist
A window appears, but it is not drawn and it cannot
On Tue Feb 27, 2024 at 7:12 AM GMT, Frank Weißer wrote:
> So we are at my original question: Which package to file a bug report ?
Package "debian-installer", I think; and/or submit an installation report,
which can be done with reportbug against the "installation-report&qu
On Tue 27/02/2024 at 22:52, David Christensen wrote:
> ...
> These appear to be the ZFS packages for the available Debian releases:
>
> https://packages.debian.org/buster/zfs-dkms
>
> busterzfs-dkms (0.7.12-2+deb10u2)
> buster-backports zfs-dkms (2.0.3-9~bpo10+1)
>
On 2/26/24 20:52, Gareth Evans wrote:
Replied to OP by mistake, reposting to list.
On Sun 25/02/2024 at 05:34, David Christensen wrote:
debian-user:
Is Debian 12.5.0 amd64 affected by OpenZFS bug #15526?
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.5.0-amd64
Marco Moock:
Am Fri, 23 Feb 2024 13:59:41 +0100
schrieb Frank Weißer :
The installer does format it as ext4, but shows ext2 and places that
in fstab, what ends up in emergency mode. That's why I'm here
That is definitely a bug.
So we are at my original question: Which package to file
On Tue 27/02/2024 at 04:52, Gareth Evans wrote:
> https://github.com/openzfs/zfs/issues/15933
>
> seems to suggest that or a similar issue is still ongoing with Open ZFS
> 2.2.3 ...
I wonder if that might be a regression, since what I think is the same issue as
openzfs #15526 appeared to be
Replied to OP by mistake, reposting to list.
On Sun 25/02/2024 at 05:34, David Christensen wrote:
> debian-user:
>
> Is Debian 12.5.0 amd64 affected by OpenZFS bug #15526?
>
> https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.5.0-amd64-netins
debian-user:
Is Debian 12.5.0 amd64 affected by OpenZFS bug #15526?
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso
https://packages.debian.org/bookworm/zfs-dkms
https://github.com/openzfs/zfs/issues/15526
David
t it manually?
> >
> The installer does format it as ext4, but shows ext2 and places that
> in fstab, what ends up in emergency mode. That's why I'm here
That is definitely a bug.
Am Fri, 23 Feb 2024 14:47:41 -0500
schrieb James Klaas :
> "Generic PCL 6/PCL XL Printer Foomatic/pxlcolor (recommended)"
Do you know the file that provides that?
If so, you apt-file search "file" to find the package that provides it.
I was going to submit a bug for this but I don't know what package I
should report the bug against.
Debian bugreport says:
Please enter the name of the package in which you have found a problem,
or type 'other' to report a more general problem. If you don't know what
package the bug
First of all: I use german during installation; but I doubt that is
relevant.
Marco Moock:
Am 22.02.2024 schrieb Frank Weißer :
I only choose ext2 for formatting the encrypted partition, because
nothing else is offered.
That is really strange. If I did install Debian 12, it offered me a
Am 22.02.2024 schrieb Frank Weißer :
> I only choose ext2 for formatting the encrypted partition, because
> nothing else is offered.
That is really strange. If I did install Debian 12, it offered me a
list of different file systems, including ext2/3/4.
> Despite that the partition in fact is
Marco Moock:
Am 22.02.2024 um 13:18:48 Uhr schrieb Frank Weißer:
I use to encrypt my swap and /var/tmp partitions during
installation.
That is LUKS.
the partition tool in debian installer offers me randomized keys
for that and has 'delete partition' set to 'yes', which costs lot
of
Am 22.02.2024 um 13:18:48 Uhr schrieb Frank Weißer:
> I use to encrypt my swap and /var/tmp partitions during installation.
That is LUKS.
> the partition tool in debian installer offers me randomized keys for
> that and has 'delete partition' set to 'yes', which costs lot of
> time, not
on reboot I end up in emergency mode.
What package have I to file the bug report against?
Please apologize my poor english.
Kind regards
readU
Frank
On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote:
What Thomas was trying to do is to get a cheap, fast random number
generator. Shred seems to have such.
You're better off with /dev/urandom, it's much easier to understand what
it's trying to do, vs the rather baroque logic in
On Tue 13 Feb 2024 at 11:21:08 (-0500), Greg Wooledge wrote:
> On Tue, Feb 13, 2024 at 09:35:11AM -0600, David Wright wrote:
> > On Tue 13 Feb 2024 at 07:15:48 (-0500), Greg Wooledge wrote:
> > > On Mon, Feb 12, 2024 at 11:01:47PM -0600, David Wright wrote:
> > > > … but not much. For me,
On Tue, Feb 13, 2024 at 01:03:44PM -0800, David Christensen wrote:
> On 2/13/24 09:40, debian-u...@howorth.org.uk wrote:
> > Greg Wooledge wrote:
> >
> > > Shred will determine the size of the file, then write data to the
> > > file, rewind, write data again, etc. On a traditional hard drive,
>
On 2/13/24 16:00, David Christensen wrote:
On 2/13/24 11:31, gene heskett wrote:
Next experiment is a pair of 4T Silicon Power SSD's When they & the
startech usb3 adapters arrive. I'll get that NAS built for amanda yet.
2.5" SATA SSD's and SATA to USB adapter cables for $187.97 + $10.99 =
On 2/13/24 09:40, debian-u...@howorth.org.uk wrote:
Greg Wooledge wrote:
Shred will determine the size of the file, then write data to the
file, rewind, write data again, etc. On a traditional hard drive,
that will overwrite the original private information. On modern
devices, it may not.
On 2/13/24 11:31, gene heskett wrote:
Next experiment is a pair of 4T
Silicon Power SSD's When they & the startech usb3 adapters arrive. I'll
get that NAS built for amanda yet.
2.5" SATA SSD's and SATA to USB adapter cables for $187.97 + $10.99 =
$198.96 each set?
On 2/13/24 14:44, Thomas Schmitt wrote:
Hi,
Gene Heskett wrote:
Next experiment is a pair of 4T Silicon Power SSD's
When f3 has (hopefully) given its OK, the topic of a full write-and-read
test will come up again. I'm looking forward to all the spin-off topics.
I'll have to admit it has
Hi,
Gene Heskett wrote:
> Next experiment is a pair of 4T Silicon Power SSD's
When f3 has (hopefully) given its OK, the topic of a full write-and-read
test will come up again. I'm looking forward to all the spin-off topics.
Have a nice day :)
Thomas
hat exactly is a bug in shred's documentation.
Plus the shell programming webinar. And a diagnosis about a rightously
failed attempt to change the partition table type from MBR/DOS to GPT.
And this all because Gene Heskett was adventurous enough to buy a cheap
fake USB disk.
Have a nice day :)
Thomas
On 2/13/24 12:56, Thomas Schmitt wrote:
Hi,
Greg Wooledge wrote:
Let me write out the example again, but with the bug fixed, and then
explain what each line does, [... lecture about advanced shell
programming ...]
And this all because Gene Heskett was adventurous enough to buy a cheap
fake
On Tue, Feb 13, 2024 at 06:54:58PM +0100, Thomas Schmitt wrote:
> Greg Wooledge wrote:
> > Let me write out the example again, but with the bug fixed, and then
> > explain what each line does, [... lecture about advanced shell
> > programming ...]
>
> And th
Hi,
Greg Wooledge wrote:
> Let me write out the example again, but with the bug fixed, and then
> explain what each line does, [... lecture about advanced shell
> programming ...]
And this all because Gene Heskett was adventurous enough to buy a cheap
fake USB disk. :))
Have a
Greg Wooledge wrote:
> Shred will determine the size of the file, then write data to the
> file, rewind, write data again, etc. On a traditional hard drive,
> that will overwrite the original private information. On modern
> devices, it may not.
Thanks for the excellent explanation :)
One
gt;"$i"
> > > > rm -- "$i"
> > > > echo "Hello, world" >&3
> > > > shred - >&3
> > > > exec 3>-
> Ironic that it truncates a file, and then immediately warns against
> truncating a file inst
calls "shred -". The documentation has to support this use
> case as well.
/As well/ — which is why I wrote N in place of 1. The original bug
report (which I hadn't seen until Thomas' post) says:
"If you redirect output to a file it will work. Shredding a tty doesn't
make muc
reg Wooledge wrote:
> In fact, that last line is
> written incorrectly. It should say "exec 3>&-" and what that does
> is close file descriptor 3, which was previously opened on line 2.
> [...]
> This is an obvious bug in the info page. I wonder how many years
> th
On Tue, Feb 13, 2024 at 07:36:14AM -0500, Greg Wooledge wrote:
> On Tue, Feb 13, 2024 at 07:15:48AM -0500, Greg Wooledge wrote:
> > This is an obvious bug in the info page. I wonder how many years
> > this has gone unnoticed.
>
> I've filed Bug#1063837 for it. <https:/
On Tue, Feb 13, 2024 at 07:15:48AM -0500, Greg Wooledge wrote:
> This is an obvious bug in the info page. I wonder how many years
> this has gone unnoticed.
I've filed Bug#1063837 for it. <https://bugs.debian.org/1063837>
previously opened on line 2.
What it actually does *as written* is create/truncate a file whose
name is "-", close the previously opened FD 3, and make FD 3 point
to the file named "-".
unicorn:~$ exec 3>-
unicorn:~$ ls -ld -- -
-rw-r--r-- 1 greg greg 0 Feb 13 07:12 -
unicorn:~$ ls -l /dev/fd/3
l-wx-- 1 greg greg 64 Feb 13 07:12 /dev/fd/3 -> /home/greg/-
This is an obvious bug in the info page. I wonder how many years
this has gone unnoticed.
On Mon, Feb 12, 2024 at 10:07:45PM +0100, Thomas Schmitt wrote:
> Hi,
>
> > https://en.wikipedia.org/wiki/Everything_is_a_file
> > But, there is more than one kind of file.
>
> "All files are equal.
> But some files are more equal than others."
>
> (George Orwell in his dystopic novel "Server
On Sun 11 Feb 2024 at 09:16:00 (-0600), David Wright wrote:
> On Sun 11 Feb 2024 at 09:54:24 (-0500), Greg Wooledge wrote:
> > On Sun, Feb 11, 2024 at 03:45:21PM +0100, to...@tuxteam.de wrote:
> > > Still there's the discrepancy between doc and behaviour.
> >
> > There isn't. The documentation
On 12/02/2024 05:41, David Christensen wrote:
Apparently, shred(1) has both an info(1) page (?) and a man(1) page. The
obvious solution is to write one document that is complete and correct,
and use it everywhere -- e.g. DRY.
https://www.gnu.org/prep/standards/html_node/Man-Pages.html
6.9
Hi,
> https://en.wikipedia.org/wiki/Everything_is_a_file
> But, there is more than one kind of file.
"All files are equal.
But some files are more equal than others."
(George Orwell in his dystopic novel "Server Farm".)
Have a nice day :)
Thomas
On 2/12/24 08:50, Curt wrote:
On 2024-02-11, wrote:
On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote:
[...]
If FILE is -, shred standard output.
=20
In every sentence, the word FILE appears. There's nothing in there
which says "you can operate on a non-file".
On Mon, Feb 12, 2024 at 04:50:50PM -, Curt wrote:
> On 2024-02-11, wrote:
> >
> >
> > On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote:
> >
> > [...]
> >
> >>If FILE is -, shred standard output.
> >>=20
> >> In every sentence, the word FILE appears. There's nothing in
On 2024-02-11, wrote:
>
>
> On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote:
>
> [...]
>
>>If FILE is -, shred standard output.
>>=20
>> In every sentence, the word FILE appears. There's nothing in there
>> which says "you can operate on a non-file".
>
> Point taken, yes.
, fast random number
generator. Shred seems to have such.
Well... I certainly wouldn't call it a bug. Maybe a feature request.
Still there's the discrepancy between doc and behaviour.
There isn't. The documentation says:
SYNOPSIS
shred [OPTION]... FILE...
I interpret the above line
.@tuxteam.de wrote:
> >
> > [...]
> >
> > > > What Thomas was trying to do is to get a cheap, fast random number
> > > > generator. Shred seems to have such.
> > >
> > > Well... I certainly wouldn't call it a bug. Maybe a feature request.
> >
> > Still th
Hi,
to...@tuxteam.de wrote:
> Still there's the discrepancy between doc and behaviour.
Depends at which documentation you look. Obviously stemming from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175#36
i read in
https://www.gnu.org/software/coreutils/manual/html_node/sh
On Sun, Feb 11, 2024 at 09:54:24AM -0500, Greg Wooledge wrote:
[...]
>If FILE is -, shred standard output.
>
> In every sentence, the word FILE appears. There's nothing in there
> which says "you can operate on a non-file".
Point taken, yes.
Cheers
--
t
signature.asc
Description:
a cheap, fast random number
> > > generator. Shred seems to have such.
> >
> > Well... I certainly wouldn't call it a bug. Maybe a feature request.
>
> Still there's the discrepancy between doc and behaviour.
There isn't. The documentation says:
SYNOPSIS
shred [OPTION]..
On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote:
> On Sun, Feb 11, 2024 at 08:02:12AM +0100, to...@tuxteam.de wrote:
[...]
> > What Thomas was trying to do is to get a cheap, fast random number
> > generator. Shred seems to have such.
>
> Well... I certainly w
-s 1K - | wc -c
> > > shred: -: invalid file type
> > > 0
> > >
> > >
> > > It looks like a shred(1) needs a bug report.
> >
> > I'm confused what you expected this command to do. You wanted to
> > "destroy" (by overwriting wi
, like:
shred -n 1 -s 204768K -v - | tee /dev/sdm1 | sha256sum
> I expect reading the code would tell.
My code analysis is in
https://lists.debian.org/msgid-search/1162291656137153...@scdbackup.webframe.org
to...@tuxteam.de found bug 155175 from 2002, which explains why. Se
> >>
> >>
> >> It looks like a shred(1) needs a bug report.
> >
> > I'm confused what you expected this command to do. You wanted to
> > "destroy" (by overwriting with random data) a pipe to wc? What
> > would that even look like?
On Sat, Feb 10, 2024 at 07:10:54PM -0500, Greg Wooledge wrote:
> On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote:
> > 2024-02-10 16:03:50 dpchrist@laalaa ~
> > $ shred -s 1K - | wc -c
> > shred: -: invalid file type
> > 0
> >
> >
> >
> > I have a bug report but am not sure which package it should be filed
> > against. The Weather Report application, version 1.24.1, is affected,
> > as is the weather reported by the Clock application, version 1.24.1, in
> > the MATE desktop environment. Neither rep
On 2/10/24 16:10, Greg Wooledge wrote:
On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote:
2024-02-10 16:03:50 dpchrist@laalaa ~
$ shred -s 1K - | wc -c
shred: -: invalid file type
0
It looks like a shred(1) needs a bug report.
I'm confused what you expected this command
On Sat, Feb 10, 2024 at 04:05:21PM -0800, David Christensen wrote:
> 2024-02-10 16:03:50 dpchrist@laalaa ~
> $ shred -s 1K - | wc -c
> shred: -: invalid file type
> 0
>
>
> It looks like a shred(1) needs a bug report.
I'm confused what you expected this command to do. Y
;.
Hmm. This looks like a genuine bug: the man page mentions it.
Also, /dev/stdout as target runs into the very same problem.
Cheers
Testing:
2024-02-10 16:01:54 dpchrist@laalaa ~
$ cat /etc/debian_version ; uname -a
11.8
Linux laalaa 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-3
On Sat, Feb 10, 2024 at 02:58:06PM +0100, Thomas Schmitt wrote:
> Hi,
>
> to...@tuxteam.de wrote:
> > Ah, it seems to be this one, from 2002:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175
>
> So it's not a bug but a feature. :(
>
> I'm riddling o
1 - 100 of 8562 matches
Mail list logo
